Comment #14 on issue 1727 by asmeurer: fix namespace clashes
http://code.google.com/p/sympy/issues/detail?id=1727
1) Integral and integrate are both necessary since integrals are
sometimes not evaluable and the user can
easily select whether to have it attempted or not by using integrate.
Yes. Indefinite summation is the same.
2) Products and sums are always easy if they have numerical limits.
True, but the issue is when one of the limits (usually the upper one) is
oo, or a variable (this is called indefinite summation, like Sum(i, (i, 1,
n))). This is kind of like saying integration is always easy if the
integrand is a polynomial. And actually, it's not necessarily so "easy,"
because if you just do it the naive way it is very inefficient.
Calculating sum(i, (i, 1, 1000000)) by adding up all the numbers from 1 to
1000000 is inefficient, noticing that it is just a special case of sum(i,
(i, 1, n)) == n*(n - 1)/2 is very efficient. So actually, if the limits
are large enough, you want to calculate the more general *indefinite* sum
first, and then substitute in the specific values (by the way, I didn't
check to see if Sum() is currently doing this).
3) There is not integrate equivalent to Product; Product is automatically
evaluated if given numerical limits:
This is a problem. Basically, Product in SymPy is very old and infantile,
partly because there doesn't exist a generic algorithm for evaluating
products like there does for indefinite summation and integration, and
partly because they are so little used that no one has really implemented
much of them. But it is clear that we should also have a product()
function.
4) giving sum a dual nature involves a performance hit on the builtin sum
result.
I agree. This appears to be the case, although to be fair it is most
likely just slower by a small constant.
5) the use of summation is grammatically ackward and long; the
grammatically correct term for the action,
summate, sounds ackward since it is not in common use.
I disagree. "sum" in the SymPy sense is short for summation. I think the
fact that it isn't a verb isn't too big of an issue; it is still clear what
it is---indeed, more so, since you now know that it is symbolic summation
and not just adding up elements of a list. I do agree that a verb is
better, but the verb in this case is "sum," and we can't use that. I feel
that summation, not summate, is the next best option.
6) Since Sum and Product are so similar they should behave the same.
I absolutely agree. But it is Product, not Sum, that needs updating here.
By the way, mathematically speaking, Sum is closer to Integrate (which is
why I have often compared the two above) than Product. The algorithm for
indefinite summation is very similar to the Risch Algorithm for indefinite
integration, and in integration theory, a summation is often just a special
case of an Integral (like a Lebesgue integral over a countable set with the
counting measure, or the Reimann-Stiltjes integral with respect to a step
function). But I digress…
And that is the time to tell them about evaluate=False (which should be
implemented for Product and Sum
in the case of receiving the keyword evaluate=False and numerical ranges.)
Maybe Ronan can have a better opinion, but it seems to me that it is better
from a design point of view to have a separate function to try doing the
action and object for the unevaluated action. Anyway, it seems to work
well for integrate. For example, if there were no integrate but only
Integral(), it would be awkward for me to have risch_integrate(). Should
that be an object that subclasses from Integral() in that case? But that
doesn't seem to work because the object itself is exactly the same (an
unevaluated integral). It is only the method of computing that object that
has changed.
Note: Sum and Product should have a unified appearance: Product arguments
are shown flat and Sum
arguments are shown within a tuple.
I agree. Product needs also to have support for multiple arguments (but
let's make the Product problems another issue).
--
You received this message because you are subscribed to the Google Groups
"sympy-issues" group.
To post to this group, send email to sympy-iss...@googlegroups.com.
To unsubscribe from this group, send email to
sympy-issues+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sympy-issues?hl=en.
