Stefan,

I just read through your proposed API. In general it seems reasonable but
Luke, Gilbert and I spoke last night on irc (logs:
http://colabti.org/irclogger/irclogger_log/sympy?date=2013-06-12) about how
to deal with immutability/mutability, subclassing from Basic/Expr, and
garbage in/out. The mechanics module has a unique use case where we have to
track the same tree of direction cosine matrices for each reference frame
involved. Currently we hide this tree on the ReferenceFrame objects and it
is a mutable entity. If you add another ReferenceFrame to the tree then
other ReferenceFrames need to know about this addition direction cosine
matrix definition. For example, in your API, when you use cart_A after
you've created cart_B it should reflect that it is rotated with respect to
cart_B. As it stands, this wouldn't happen if the frames are immutable. You
could imagine having this tree held in your world object but it would also
need to be mutable.

I think we, @mechanics, will be fine with most of what you all proposed if
we can clearly see that ReferenceFrame (plus velocities, accelerations)
will be properly tracked. Our module's cornerstone are these trees that
relate reference frames together.

Some summary from our conversation:

1. We're fine with immutability and subclassing from Basic if there is a
mechanism in place that can handle reference frame relationships correctly
and accurately.
2. We're more found of garbage in, throw an error for funny things like vec
* vec or scalar + vec. Seems like you have that in your api proposal.



Jason
moorepants.info
+01 530-601-9791


On Wed, Jun 12, 2013 at 8:35 AM, Prasoon Shukla <prasoon92.i...@gmail.com>wrote:

>
>
> On Wednesday, June 12, 2013 7:52:34 PM UTC+5:30, Stefan Krastanov wrote:
>>
>> > For the mutability issue : Just as Aaron suggested, we do really need
>> the
>> > objects to be mutable. Doing something as
>>
>> If I understand correctly, Aaron's main point was that mutability is
>> useful only in certain cases and I do not think that the current
>> module requires it. Most of the arguments in favor of mutability were
>> about how to relate two reference frames (both static translation and
>> orientation as well as relative velocity and angular velocity). I
>> think that the example I provided addresses these issue and mutability
>> is not necessary.
>>
>
> Oh! I'm really sorry :P I meant
> > ... we do *not* really need the objects to be mutable. Doing something
> as ....
>
> Little typo, big confusion :)
>
> --
> 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.


Reply via email to