@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 <[email protected]> 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 > <[email protected]>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 >> [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. > > > -- 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.
