wrong result with series

Re: args invariant

Google Summer of Code

args invariant

I think Matthew wanted to delay this discussion until the end of the
summer, but I'd like to start it now while it is fresh on my mind.  I
am currently writing the expression manipulation part of the new
tutorial (http://docs.sympy.org/tutorial/tutorial/manipulation.html),
and this issue is central to my discussion.

There has been some discussion from time to time about the invariants
that SymPy objects are supposed to follow.  The invariants are
something like "all elements of an object's .args should be instances
of Basic" and "all Basic objects should be rebuildable from their
args, like obj.func(*obj.args) == obj".

The main discussion has been about the first one. Should we allow
non-Basic args?  The common example if Symbol.  Currently, Symbol('x')
has empty args.  The proposal would make Symbol('x').args be ('x',).
The same for Integer. Integer(2).args is just (), but the proposal
would make it (int(2),).

But notice that the two invariants as I stated them above are
inconsistant, because Symbol('x') is not rebuildable from its args
unless its args are ('x',).

I have started a wiki page to gather my thoughts on this at
https://github.com/sympy/sympy/wiki/Args-Invariant.  Basically, I
think there are basically two ways that we should go, which are called
option 1 and option 3 on the wiki page (option 2 is something I think
we should throw out immediately).  The question boils down to what a
leaf in an expression tree is. The rest follows from that.  The
options are

1. Any non-Basic
3. Any object with empty args

If we choose option 1, then the invariant becomes `obj.func(*obj.args)
== obj`. If we choose option 2, then the invariant becomes `obj.args
== () or obj.func(*obj.args) == obj`.

Now, I don't think it's any secret that I prefer option 3, and that
some people in the community (namely Matthew and Stefan) have been
arguing for option 1, but I think we should work out all the
differences, and pick the best one.

So without making this email twice as long as it already is, I refer
you to the wiki page, where I've started an extensive comparison of
the two options.  Feel free to edit it to add more pros/cons,
examples, or to fix the formatting.

I've also created a section of the wiki page on the bottom for
opinions. Please keep the main part to facts, and put your opinions at
the bottom.  We can also discuss opinions here on the mailing list.

Aaron Meurer

--

-- 
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+unsubscribe@...
To post to this group, send email to sympy@...
Visit this group at http://groups.google.com/group/sympy?hl=en-US.
For more options, visit https://groups.google.com/groups/opt_out.

real=True as argument to Function

Surface_color

solve() questions

I'm writing the part of the new tutorial on solve().  I have some questions

- What is a good example of an equation that has a solution, but which
cannot be represented symbolically (as an example of when solve()
might return no solutions for this reason)?

- I thought we decided to remove NotImplementedError from solve(). Or
was that just None?

- The lack of a consistant return type is killing me. It seems the
type depends not just on whether you are solving one or two equations,
but also on the *type* of the equations!

In [5]: solve([x - 1, y - 1], [x, y])
Out[5]: {x: 1, y: 1}

In [6]: solve([x**2 - 1, y - 1], [x, y])
Out[6]: [(-1, 1), (1, 1)]

Is there a reason that we don't set `dict=True` by default, at least
for systems of equations?

I'm tempted to not even discuss solving systems of equations at all,
because the lack of a consistant return type would just make the
discussion too confusing for new users (and embarrassing for us).

Aaron Meurer

--

-- 
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+unsubscribe@...
To post to this group, send email to sympy@...
Visit this group at http://groups.google.com/group/sympy?hl=en-US.
For more options, visit https://groups.google.com/groups/opt_out.

Cyclic groups

Exp map of DifferentialOperator

How to run `setup.py test` from specific point

Unable to import sympy