Just to be clear about something, SymPy does not assume that removable
discontinuities are as defined by default. If you do
(sin(x)/x).subs(x, 0), you get nan, which is the result of 0/0. The
same goes for x**2/(x**2 + x).
Now, simplify will transform the latter expression into something that
doesn't strictly have the same definition at 0 (it removes the
singularity).
And x**a*x**b will automatically combine into x**(a + b) if a and b
have the same "term" in a coeff-term expansion (like
x**(2*y)*x**(4*y)). If it didn't do this, then x*x would not simplify
into x**2. OK, let's do that, but not if one of the exponents is
negative you say. Or rather, if one of the exponents is negative but
the resulting exponent is nonnegative. But what about exp(2)*exp(-2)
=> 1. That doesn't remove any information. exp(x)*exp(-x) => 1
doesn't even remove any information, as exp(x) can never be 0. And
what about x**(2*n)*x**-n, where n is Symbol('n', negative). So now
we start checking all kinds of assumptions in the core. And not just
anywhere in the core: in Mul.flatten, one of the most important
routines in the core as far as performance is concerned.
If you want to keep track of the numerator and denominator, I suggest
you keep them separate. They won't cancel on their own if you do
that. http://code.google.com/p/sympy/issues/detail?id=1966 would
allow you to create x/x without it canceling (actually, you can
already do it with Mul(x, 1/x, evaluate=False), but it's not as easy
as that issue would allow). But even then, I would recommend just
keeping the separate.
As far as assuming removable discontinuities are defined by continuous
extension being the standard practice, I think it depends on what you
are doing. In complex analysis, and any field that uses that kind of
math (like Physics), this is common, because removable singularities
aren't very interesting. This field also commonly assumes analytic
continuation too, so things like Sum(1/t**z, (t, 1, oo)) are assumed
to be defined for all z in the complex plane except for z = 1, even
though the sum only converges for Re(z) > 1. Definitely every other
field of mathematics I've encountered is more careful about this,
though.
I personally think SymPy strikes a good balance with this. As long as
you understand the behavior of various operations, and don't use too
many magic functions (like simplify()), there shouldn't be too many
surprises. At the worst, you'll get nan where you expected a number,
and that should be a sign to you that you need to use limit() or do
something else to get around a removable discontinuity.
Aaron Meurer
On Wed, Jan 11, 2012 at 2:16 PM, [email protected]
<[email protected]> wrote:
>
>
> On 11 January 2012 21:44, Joachim Durchholz <[email protected]> wrote:
>>
>> Am 11.01.2012 11:32, schrieb Alexey U. Gudchenko:
>>>
>>> 11.01.2012 12:51, Joachim Durchholz пишет:
>>>>
>>>> x²/x has a discontinuity for x=0, and x does not, hence x²/x is not the
>>>> same as x.
>>>
>>>
>>> No, no, it is continuous because the limit when x-->0 exists (equals 0),
>>
>>
>> The limit exists, but that's just half of the definition of "continuous".
>>
>>
>> > and the same as a value of function at this point, 0**2/0 (which by
>>>
>>> definition is equal 0).
>>
>>
>> f(x) = x²/x has no definition for x=0. It involves division by zero.
>>
>> If you go from functions to relations, then for a, b != 0, we have
>> - a/b is a one-element set
>> - a/0 is the empty set since no r satisfies 0*r = a
>> - 0/0 is the the set of all values since all r satisfy 0*r = 0
>> So you can assign an arbitrary value to the result of 0/0 and it will be
>> "correct", but you don't know whether the value you assigned is "more" or
>> "less" correct than any other.
>> For example, what should (x²/x)/(x²/x) be for x=0?
>> If you do the x-->0 limit first, you'll get 1.
>> If you stick with the basic substitutability rules of math, you get
>> (x²/x)/(x²/x) = (0)/(0) = 0/0 = 0.
>
> If you stick to the basic substitution rules you completely ignore the way
> this behaves *around but not at* zero. And 0/0 is not 0. It's undefined.
>>
>> Hilarity ensues.
>>
>> Oh, and I bet different people will have different assumptions about which
>> rule should take priority.
>> And if their assumptions differ from those that simplify() applies, they
>> will come here and ask what's wrong.
>>
>> Regards,
>> Jo
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "sympy" group.
>> To post to this group, send email to [email protected].
>> To unsubscribe from this group, send email to
>> [email protected].
>> For more options, visit this group at
>> http://groups.google.com/group/sympy?hl=en.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected].
> For more options, visit this group at
> http://groups.google.com/group/sympy?hl=en.
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sympy?hl=en.
