@Stefan. I agree about the tree traversals part. However, I still feel there must be a way for the user to check if two scalar fields expressed in different ways are mathematically equivalent. Could you suggest a way? Maybe just another function? Also, have a look at the __eq__ function of the current Vector class. I would really like atleast _some_ way of checking mathematical equality. I think we should let everyone opine on this equality thing, because it will, as you said, affect the entire framework, even Vector. @Jason, Aaron, Luke, Sean.... thoughts?
On Mon, Jun 10, 2013 at 5:53 PM, Stefan Krastanov < krastanov.ste...@gmail.com> wrote: > @Gilbert > > > If you have the same scalar field, written in a rectangular coordinate > system as x * y * z and in a spherical coordinate system as > r*sin(theta)*cos(phi) * r*sin(theta)*sin(phi) * r*cos(theta), and these two > coordinate systems have the same orientation and origin, the scalar fields > should be equivalent, right? Should they also evaluate as the same in SymPy? > > They should not - `__eq__` checks for structural equality of the > expression tree, not for mathematical equality. Actually, even trying to > get these expression to evaluate to the same thing is futile - it is not > possible in general (just getting trigonometry involved will probably be > sufficient to make the expressions to complex.) > > @Sachin > > > 3. To ensure field1 == field2 returns True if the fields are indeed > equal (mathematically) > > This is one of the most problematic antipatterns in sympy. Everytime this > is done it breaks most of the tree manipulation routines, from `subs` > through `atoms` to `simplify`. Please look at the sympy core, tree > traversal, etc so you know why we need to be careful about `__eq__` and > `__hash__`. > > Sorry for nor answering sooner, but I was traveling the last two days. > > I actually do not think the api design is anywhere near completion. Many > of the issues are not addressed: > > - dependence of string flags in many constructors that seem redundant > given the creation of objects meant to represent the same thing (for > instance the creation of points) > - ScalarField class - All of the arguments for seem very vague. Two > arguments against are as follows: Very seriously breaks tree traversal > (which is the most fundamental part of sympy) and requires reimplementation > of practially every operator (+ - / * etc). Just consider what happens when > I want to take exp(some_scalar_field). > - Many of the issues surrounding ScalarField are relevant also for Vector. > > > > > On 10 June 2013 11:45, Sachin Joglekar <srjoglekar...@gmail.com> wrote: > >> +1. >> I added one or two comments, they are mostly just clarifications. But I >> guess we agree on the basics now. >> I will post some hand-written scanned stuff about the math of Stefan's >> stress test on my blog in a day, mainly to clarify things in my own mind as >> well. >> Prasoon, could you expand on the convective derivative part? Apart from >> that, I think my blog post + our wiki will clear it all up. >> @Stefan, Prasoon, Gilbert - How do you guys think we should proceed with >> coding? >> >> >> On Mon, Jun 10, 2013 at 3:04 PM, Prasoon Shukla <prasoon92.i...@gmail.com >> > wrote: >> >>> I have made some comments on the wiki. Let us get the API decided so >>> that both I and Sachin can get started with some work. Thanks. >>> >>> -- >>> 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 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.
