It seems like mechanics applications operate on a deep tree of objects. Is
it correct to put all of these inside SymPy? The lower levels should
certainly be SymPy objects but perhaps some of the higher levels are
sufficiently application-centric and require enough performance that they
should break with SymPy's model of expression trees.
Again, I know very little of the details of what you all are working on,
but maybe there is a place in the organization at which the SymPy model
stops and generic Python code takes over. This is just a though, please
don't consider it too strongly.
On Thu, Jun 13, 2013 at 9:38 AM, Gilbert Gede <gilbertg...@gmail.com> wrote:
> I'd like to reiterate the concerns of the mechanics people, in that there
> needs to be a more serious consideration of ReferenceFrames and the
> end-users' ability to make changes to them after they are instantiated.
> It's easy to gloss over this problem when you're looking at one or two
> frames, but when you start looking at 10 or 20 (which is not uncommon for
> multibody systems) the user effort in managing the relationship tree has to
> be considered.
>
> I'm also not completely comfortable with the garbage-in/garbage-out
> philosophy being used with something (physics.mechanics) that is an
> engineering tool. It seems like a few checks on the "validity" of generated
> vectors are being considered, but I agree with Stefan in that you need to
> be more explicit in how some of these details will be handled, and I am
> concerned with how robust they are. If we can successfully subclass from
> Expr, that would be great. I think it needs to be considered against the
> downsides though.
>
> -Gilbert
>
>
>
> On Thu, Jun 13, 2013 at 6:57 AM, Stefan Krastanov <
> krastanov.ste...@gmail.com> wrote:
>
>> I do not see any problem with using MatExpr instead of Expr for this
>> GSoC project. The only difference from what we discussed on IRC
>> yesterday is that instead of using Symbol as a superclass for
>> BaseScalarField (i.e. x y z) and BaseVector (i.e. the unit vectors
>> along x y z) you will use MatrixSymbol for the vectors and Symbol for
>> the scalars.
>>
>> However, I do not know well all the details around MatExpr - if you
>> choose this path, please explain why (and give actual examples, not
>> just statements like "garbage detection will be easier"). I insist on
>> this, because currently the only problems with using Expr seems to be
>> garbage detection, which can simply be postponed to function calls
>> (much like the use of sympify).
>>
>> On 13 June 2013 15:36, Sachin Joglekar <srjoglekar...@gmail.com> wrote:
>> > Personally, I like Mathew's idea of using MatrixExprs to represent
>> vectors.
>> > This will not just ensure smooth functioning with the rest of sympy, but
>> > will also help in easing the 'garbage detection' process. Plus,
>> > representation (as well as stuff like pretty printing) would get easier.
>> > The only 'oddity', once again, would be vectors that are an addition of
>> > bases from two different frames. Maybe use something on the lines of
>> MatAdd?
>> >
>> >
>> > On Thu, Jun 13, 2013 at 6:55 PM, Matthew Rocklin <mrock...@gmail.com>
>> wrote:
>> >>
>> >> I don't remember enough of the details to give you a comprehensive
>> answer.
>> >> Here are a few thoughts that come to mind.
>> >>
>> >> You won't be able to change much of the Add and Mul code to handle
>> >> Vectors. For example you won't be able to add shape checking at
>> >> construction time. This forces you to follow the "Garbage in, Garbage
>> out"
>> >> philosophy (which isn't necessarily bad)
>> >>
>> >> In [18]: A = MatrixSymbol('A', n, 1)
>> >> In [19]: B = MatrixSymbol('B', m, 1)
>> >> In [20]: x = Symbol('x')
>> >> In [21]: Add(x, A, B)
>> >> Out[21]: x + A + B
>> >>
>> >> In [22]: MatAdd(x, A, B)
>> >> TypeError: Mix of Matrix and Scalar symbols
>> >>
>> >> In [23]: MatAdd(A, B)
>> >> ShapeError: Matrices A and B are not aligned
>> >>
>> >> Add and Mul inherit from Expr. The Expr codebase in general assumes
>> that
>> >> its elements are scalars. This pops up in many of the methods on Expr
>> >> classes.
>> >>
>> >> In [26]: Mul(A, A, B)
>> >> AttributeError: 'MatrixSymbol' object has no attribute 'as_base_exp'
>> >>
>> >> I really don't think I should have to implement as_base_exp for
>> matrices
>> >> but I do if I want to use Mul. Actually this sort of thing usually
>> isn't so
>> >> bad, the defaults you get from inheriting from Expr are reasonable. I
>> >> remember having lots of trouble with some of the more aggressive scalar
>> >> functions. People kept using expand and factor on matrix expressions.
>> They
>> >> sometimes got errors and filed bug reports that were very difficult to
>> >> resolve without completely rewriting these functions to be more
>> general.
>> >>
>> >> Using Mul and Add is fine. It'll work for a while. Every once in a
>> while
>> >> you'll come across a wart. I'm personally biased against the Expr
>> codebase;
>> >> I think it's the result of a lot of glomming on of special cased code.
>> By
>> >> my aesthetic MatrixExprs are a lot cleaner and more extensible. I'm
>> >> personally happy with the choice not to inherit from Expr. Other
>> groups
>> >> have gone other ways though. You could look at physics.quantum if you
>> >> wanted to see how Exprs work on non-scalars.
>> >>
>> >> Also, just a thought, but if you're just using vectors you could
>> >> presumably build off of MatrixExprs. The container classes (MatAdd,
>> MatMul)
>> >> make very few assumptions about the things they hold other than that
>> they
>> >> are Basics and have a shape.
>> >>
>> >>
>> >> On Thu, Jun 13, 2013 at 1:52 AM, Prasoon Shukla <
>> prasoon92.i...@gmail.com>
>> >> wrote:
>> >>>
>> >>> @Matthew Rocklin:
>> >>>
>> >>> Can you please tell what exactly would be the advantage of having a
>> >>> separate VectAdd class? I mean I don't see the problems with using the
>> >>> current Add and Mul classes.
>> >>>
>> >>> --
>> >>> 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 a topic in the
>> >> Google Groups "sympy" group.
>> >> To unsubscribe from this topic, visit
>> >>
>> https://groups.google.com/d/topic/sympy/t-Je0beTIIU/unsubscribe?hl=en-US.
>> >> To unsubscribe from this group and all its topics, 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.
>> >
>> >
>>
>> --
>> 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.
>
>
>
--
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.
