I am catching up here, so just some random comments on things that were mentioned:
- Regarding the quantum module, they actually went the opposite route from MatrixExprs. Originally, they used their own QAdd, QMul, etc., but then later it was changed to use the core Add, Mul, etc. I don't remember the exact reasons. Brain can comment better. - I agree with Stefan about garbage in, garbage out. I'm assuming "garbage" here means things like vector + scalar. It's true that the core does not currently let you enforce things like this (issue 1941 again), but I think it's fine. Just create expressions that are scalar linear combinations of vectors. Then in the vector superclass, write a little helper function that parses this into a more workable format, and does validation. If you want, you could even perform some magic to make this as painless (i.e., automatic) as possible. - Regarding mutability, don't do it. It breaks the SymPy conventions, and there's really no good reason to have it. Unless you are dealing with large data structures that should not be copied in memory, mutability is just the difference between expr.operation_inplace() and expr = expr.operation() The benefit to immutability is that you don't have global state (and if you don't think that global state is a bad thing, then you've never accidentally written "def func(x=[]):"). It's also easier to write branched code flow, because you don't have to explicitly copy your objects (ever modified a list while looping through it?). - What does your planned API look like regarding functions and methods? If it is method heavy, then making everything a Vector will be more important. - Unrelated, but I'm curious. What will Vector*Vector do? Aaron Meurer On Tue, Jun 11, 2013 at 2:26 PM, Matthew Rocklin <mrock...@gmail.com> wrote: > > > > On Tue, Jun 11, 2013 at 2:16 PM, Gilbert Gede <gilbertg...@gmail.com> wrote: >> >> Prasoon, >> That option does not work for ReferenceFrame. If I have a ReferenceFrame >> A, and another ReferenceFrame B, and want to set the angular velocity of B >> in A as >> w_1*b_1 + w_2_* b_2 + w_3 * b_3 >> I need access to the basis vectors of B, which I won't have until after >> the frame is initialized. Another situation that can occur is the angular >> velocity being defined as: >> w_1*b_1 + w_2_* b_2 + w_3 * b_3 + w_k * a_1 >> I don't see any way around ReferenceFrame being mutable if you want to >> maintain the same functionality that is in mechanics now. >> As for having a separate CoordinateSystem and ReferenceFrame: I think it >> is better to keep these explicit ideas separate if writing two classes >> doesn't result in much code overlap. > > > Mutability makes me sad :-( > I haven't read enough to comment on all of this any degree of intellect; I'm > merely promoting principles. > >> >> Stefan, regarding your concerns about Vector eating everything up - isn't >> that how it should be? Once you are dealing with Vectors, won't most >> operations will result in a Vector? Matthew's suggestion to implement our >> own VectorAdd/VectorMul seems like it might work though. >> >> Also, is there a way to blacklist what functions are allowed to perform on >> Vectors? > > > Blacklisting in inheritance is possible but apparently looked down upon. If > you use Expr container classes (Add, Mul) it's likely that these methods > will eventually be called upon in any event. > http://stackoverflow.com/questions/16749312/remove-attribute-from-subclass-in-python > > > -- > 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 sympy+unsubscr...@googlegroups.com. > To post to this group, send email to sympy@googlegroups.com. > 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 sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy?hl=en-US. For more options, visit https://groups.google.com/groups/opt_out.
