A Problem with Simplify
Kevin J. McCann
evaluate to zero if m is not equal to n and to L/2 if they are the same.
The following is just fine
Imn = Simplify[Integrate[
Sin[(m*Pi*x)/L]*
Sin[(n*Pi*x)/L],
{x, 0, L}]]
However, if I specify that m and n are integers, I only get the
"general" solution of zero, i.e. when m and n are not equal.
Imn = Simplify[Integrate[
Sin[(m*Pi*x)/L]*
Sin[(n*Pi*x)/L],
{x, 0, L}],
Element[m, Integers] &&
Element[n, Integers]]
The workaround is obvious in this case, but shouldn't mma give multiple
answers? Perhaps something similar to what it already does with Integrate?
Kevin
--
Kevin J. McCann
Research Associate Professor
JCET/Physics
Physics Building
University of Maryland, Baltimore County
1000 Hilltop Circle
Baltimore, MD 21250
dh
Hi Kevin,
the culprit is Integrate not Simplify. In the manual one finds:
"For indefinite integrals, Integrate tries to find results that are
correct for almost all values of parameters."
I think this to be a trap for the unwary.
hope this helps, Daniel
Kevin J. McCann wrote:
> I have the following rather simple integral of two sines, which should
> evaluate to zero if m is not equal to n and to L/2 if they are the same.
>
> The following is just fine
>
> Imn = Simplify[Integrate[
> Sin[(m*Pi*x)/L]*
> Sin[(n*Pi*x)/L],
> {x, 0, L}]]
>
>
> However, if I specify that m and n are integers, I only get the
> "general" solution of zero, i.e. when m and n are not equal.
>
> Imn = Simplify[Integrate[
> Sin[(m*Pi*x)/L]*
> Sin[(n*Pi*x)/L],
> {x, 0, L}],
> Element[m, Integers] &&
> Element[n, Integers]]
>
> The workaround is obvious in this case, but shouldn't Mathematica give multiple
Alexey Popkov
Mathematica 6.0 for Microsoft Windows (32-bit)
Copyright 1988-2008 Wolfram Research, Inc.
In[1]:= Imn = Integrate[Sin[(m*Pi*x)/L]*Sin[(n*Pi*x)/L], {x, 0, L}];
In[2]:= Imn // InputForm
Out[2]//InputForm= (L*n*Cos[n*Pi]*Sin[m*Pi] - L*m*Cos[m*Pi]*Sin[n*Pi])/
(m^2*Pi - n^2*Pi)
In[3]:= Simplify[Imn, Assumptions -> n == m]
L n Cos[n Pi] Sin[m Pi] - L m Cos[m Pi]
Sin[n Pi]
Simplify::infd: Expression
------------------------------------------------- simplified to
2 2
m Pi - n Pi
Indeterminate.
Out[3]= Indeterminate
But:
In[4]:= Integrate[Sin[(n*Pi*x)/L]*Sin[(n*Pi*x)/L], {x, 0, L}] //
InputForm
Out[4]//InputForm= (L*(2 - Sin[2*n*Pi]/(n*Pi)))/4
This is a bug! :(
Recently I also have found another strange bug in Simplfy (not so
dangerous):
FullSimplify[Sin[x]*Cos[x]]
gives Sin[x]*Cos[x] instead Sin[2*x]/2. The workaround is
FullSimplify[2*Sin[x]*Cos[x]]/2.
Kevin J. McCann wrote:
> I have the following rather simple integral of two sines, which should
> evaluate to zero if m is not equal to n and to L/2 if they are the same.
>
> The following is just fine
>
> Imn = Simplify[Integrate[
> Sin[(m*Pi*x)/L]*
> Sin[(n*Pi*x)/L],
> {x, 0, L}]]
>
>
> However, if I specify that m and n are integers, I only get the
> "general" solution of zero, i.e. when m and n are not equal.
>
> Imn = Simplify[Integrate[
> Sin[(m*Pi*x)/L]*
> Sin[(n*Pi*x)/L],
> {x, 0, L}],
> Element[m, Integers] &&
> Element[n, Integers]]
>
> The workaround is obvious in this case, but shouldn't Mathematica give multiple
David W.Cantrell
> I have the following rather simple integral of two sines, which should
> evaluate to zero if m is not equal to n and to L/2 if they are the same.
That's right, assuming also that m and n are integers.
> The following is just fine
>
> Imn = Simplify[Integrate[Sin[(m*Pi*x)/L]*Sin[(n*Pi*x)/L], {x, 0, L}]]
Is it really "just fine"? The result of Integrate (on which Simplify has no
effect here) is
(L*n*Cos[n*Pi]*Sin[m*Pi] - L*m*Cos[m*Pi]*Sin[n*Pi])/(m^2*Pi - n^2*Pi)
That result is indeed fine if m and n are different, but it is
Indeterminate, which is surely not what you want, when m and n are equal.
> However, if I specify that m and n are integers, I only get the
> "general" solution of zero, i.e. when m and n are not equal.
>
> Imn = Simplify[Integrate[Sin[(m*Pi*x)/L]*Sin[(n*Pi*x)/L], {x, 0, L}],
> Element[m, Integers] && Element[n, Integers]]
>
> The workaround is obvious in this case, but shouldn't Mathematica give multiple
> answers? Perhaps something similar to what it already does with
> Integrate?
The reason that the above gave simply 0 is that, for integer m and n, the
numerator is 0 and
In[5]:= 0/x
Out[5]= 0
_irrespective_ of x (which, for all we know, might be 0).
Note that getting 0 for Out[5] did not even require an invocation of
Simplify.
But I do have a "solution" for your "problem", assuming that you're using
version 6, which introduced the function Sinc. Let's consider an indefinite
integral:
An antiderivative of Sin[p x] Sin[q x] wrt x is
x/2 (Sinc[(p - q) x] - Sinc[(p + q) x])
_regardless_ of whether p and q are different or the same.
Of course, it's easy then to use that antiderivative to evaluate your
definite integral. It's
L/2 (Sinc[(m - n) Pi] - Sinc[(m + n) Pi])
which is valid regardless of whether m and n are integer or whether they
are equal or not.
If you're interested in reading more about how Sinc can be used in such
cases and in other applications, see my article "-- Sinc relatives, with
applications" at
<http://groups.google.com/group/sci.math/msg/34165f71a3bb2c63>.
David W. Cantrell
Andrzej Kozlowski
I don't think it would be reasonable to expect it to do so. The reason
is that unlike definite Integration (which does) Simplify is
frequently used as part of code for other functions (including built
in functions) and returning conditional answers could have a dramatic
impact on complexity and what's worse, would only make sense if other
functions also returned conditional answers (and accepted conditional
input). It just does not seem practical now or in any foreseeable
future.
Andrzej Kozlowski
On 10 Apr 2008, at 15:12, Kevin J. McCann wrote:
> I have the following rather simple integral of two sines, which should
> evaluate to zero if m is not equal to n and to L/2 if they are the
> same.
>
> The following is just fine
>
> Imn = Simplify[Integrate[
> Sin[(m*Pi*x)/L]*
> Sin[(n*Pi*x)/L],
> {x, 0, L}]]
>
>
> However, if I specify that m and n are integers, I only get the
> "general" solution of zero, i.e. when m and n are not equal.
>
> Imn = Simplify[Integrate[
> Sin[(m*Pi*x)/L]*
> Sin[(n*Pi*x)/L],
> {x, 0, L}],
> Element[m, Integers] &&
> Element[n, Integers]]
>
> The workaround is obvious in this case, but shouldn't Mathematica give
> multiple
> answers? Perhaps something similar to what it already does with
> Integrate?
>
Jens-Peer Kuska
the problem is Integrate[] and not simplify because
Integrate[Sin[(n*Pi*x)/L]*Sin[(n*Pi*x)/L], {x, 0, L}]
is different from
Integrate[Sin[(m*Pi*x)/L]*Sin[(n*Pi*x)/L], {x, 0, L}]
and Mathematica should integrate twice.
Regards
Jens
Kevin J. McCann wrote:
> I have the following rather simple integral of two sines, which should
> evaluate to zero if m is not equal to n and to L/2 if they are the same.
>
> The following is just fine
>
> Imn = Simplify[Integrate[
> Sin[(m*Pi*x)/L]*
> Sin[(n*Pi*x)/L],
> {x, 0, L}]]
>
>
> However, if I specify that m and n are integers, I only get the
> "general" solution of zero, i.e. when m and n are not equal.
>
> Imn = Simplify[Integrate[
> Sin[(m*Pi*x)/L]*
> Sin[(n*Pi*x)/L],
> {x, 0, L}],
> Element[m, Integers] &&
> Element[n, Integers]]
>
> The workaround is obvious in this case, but shouldn't Mathematica give multiple
Jean-Marc Gulliet
<snip>
> Recently I also have found another strange bug in Simplfy (not so
> dangerous):
> FullSimplify[Sin[x]*Cos[x]]
> gives Sin[x]*Cos[x] instead Sin[2*x]/2. The workaround is
> FullSimplify[2*Sin[x]*Cos[x]]/2.
<snip>
This is not a bug, indeed. As a rule of thumb, *FullSimplify* tries to
minimize the leaf count of the expression.
For the case above, the original expression sin(x)cos(x) has a leaf
count of 5 whereas the trigonometric identity sin(2x)/2 has a leaf count
of 8. Therefore, *FullSimplify* returns the original form sin(x)cos(x)
since it is deemed as simpler than sin(2x)/2 w.r.t. the lead count of
each expression.
Note that, in general, you can modify/tweak this default behavior to
suit your needs by witting your own *ComplexityFunction*. However, when
dealing with trigonometric expressions (especially when looking for some
trigonometric identities) it is usually better and less cumbersome to
use *TrigReduce* and the like (*TrigExpand*, *TrigFactor*, etc.).
FullSimplify[Sin[x]*Cos[x]] (* returns Cos[x] Sin[x] *)
% // LeafCount (* returns 5 *)
TrigReduce[Sin[x]*Cos[x]] (* returns 1/2 Sin[2 x] *)
% // LeafCount (* returns 8 *)
LeafCount[Cosh[x] - Sinh[x]] (* returns 7 *)
FullSimplify[Cosh[x] - Sinh[x]] (* returns E^-x *)
% // LeafCount (* returns 5 *)
Best regards,
-- Jean-Marc
Andrzej Kozlowski
example was discussed here quite recently).
The usual argument is that Mathematica adopts a "generic" approach,
whatever that means. I don't much like this way of thinking because
such a concept of "genericity" is hard to formalize. Instead I have my
own way of thinking about this, which at least satisfies me on this
score. Essentially, I think of all Mathematica expressions as
belonging to some formal algebraic system, a "partial algebra" (you
can formally add and multiply most expressions although not quite all,
and you can even multiply then by "scalars"). There are certain "built
in" relations that hold between certain expressions in the algebra and
other relations can be introduced by the user. Any two different
symbols are always different, unless there is a built in relationship
or a user defined relationship that says otherwise. Hence the answer
returned by
Assuming[Element[m | n, Integers],
Simplify[Integrate[Sin[(m*Pi*x)/L]*Sin[(n*Pi*x)/L], {x, 0, L}]]]
0
is completely correct in my interpretation and not just "generically
correct" because in my interpretation m and n are not equal simply by
virtue of being different Mathematica expressions. On the other hand:
Assuming[Element[m | n, Integers] && m == n,
Simplify[Integrate[Sin[(m*Pi*x)/L]*Sin[(n*Pi*x)/L], {x, 0, L}]]]
L/2
is also O.K. because we performed the simplification with the user
introduced relation m==n.
So, with my interpretation (different symbols are always different
quantities unless stated otherwise) all is well.
Andrzej Kozlowski
On 10 Apr 2008, at 21:12, Kevin J. McCann wrote:
> Perhaps, but the answer returned is incorrect. Perhaps it would be
> better to return nothing?
>
> Kevin
>
> Andrzej Kozlowski wrote:
>> Simplify does not return conditional answers (in the form If[..])
>> and I don't think it would be reasonable to expect it to do so. The
>> reason is that unlike definite Integration (which does) Simplify is
>> frequently used as part of code for other functions (including
>> built in functions) and returning conditional answers could have a
>> dramatic impact on complexity and what's worse, would only make
>> sense if other functions also returned conditional answers (and
>> accepted conditional input). It just does not seem practical now or
>> in any foreseeable future.
>>
>> Andrzej Kozlowski
>>
>>
>> On 10 Apr 2008, at 15:12, Kevin J. McCann wrote:
>>> I have the following rather simple integral of two sines, which
>>> should
>>> evaluate to zero if m is not equal to n and to L/2 if they are the
>>> same.
>>>
>>> The following is just fine
>>>
>>> Imn = Simplify[Integrate[
>>> Sin[(m*Pi*x)/L]*
>>> Sin[(n*Pi*x)/L],
>>> {x, 0, L}]]
>>>
>>>
>>> However, if I specify that m and n are integers, I only get the
>>> "general" solution of zero, i.e. when m and n are not equal.
>>>
>>> Imn = Simplify[Integrate[
>>> Sin[(m*Pi*x)/L]*
>>> Sin[(n*Pi*x)/L],
>>> {x, 0, L}],
>>> Element[m, Integers] &&
>>> Element[n, Integers]]
>>>
>>> The workaround is obvious in this case, but shouldn't Mathematica give
>>> multiple
>>> answers? Perhaps something similar to what it already does with
>>> Integrate?
>>>
>>> Kevin
Andrzej Kozlowski
On 11 Apr 2008, at 14:42, Alexey Popkov wrote:
> Recently I also have found another strange bug in Simplfy (not so
> dangerous):
> FullSimplify[Sin[x]*Cos[x]]
> gives Sin[x]*Cos[x] instead Sin[2*x]/2. The workaround is
> FullSimplify[2*Sin[x]*Cos[x]]/2
This is not a bug!
In[7]:= LeafCount[Sin[x]*Cos[x]]
Out[7]= 5
In[8]:= LeafCount[Sin[2*x]/2]
Out[8]= 8
In other words, Sin[x] Cos[x] is considered simpler by Simplify than
Sin[2*x]/2, that's all. Indeed:
In[9]:= Simplify[Sin[2*x]/2]
Out[9]= Cos[x]*Sin[x]
If you want Simplify to return Sin[2*x]/2 use a different complexity
functions:
Simplify[Sin[x]*Cos[x], ComplexityFunction ->
(LeafCount[#1] + 10*Count[#1, _Cos,
Infinity] & )]
(1/2)*Sin[2*x]
And, by the way, your "other bug" is also not a bug.
A basic principle worth remembering: just because something seems
wrong to you does not mean it is wrong.
Andrzej Kozlowski
Alexey Popkov
> On 11 Apr 2008, at 14:42, Alexey Popkov wrote:
>
> > Recently I also have found another strange bug in Simplfy (not so
> > dangerous):
> > FullSimplify[Sin[x]*Cos[x]]
> > gives Sin[x]*Cos[x] instead Sin[2*x]/2. The workaround is
> > FullSimplify[2*Sin[x]*Cos[x]]/2
>
> This is not a bug!
>
> In[7]:= LeafCount[Sin[x]*Cos[x]]
> Out[7]= 5
>
> In[8]:= LeafCount[Sin[2*x]/2]
> Out[8]= 8
>
> Sin[2*x]/2, that's all. Indeed:
>
> In[9]:= Simplify[Sin[2*x]/2]
> Out[9]= Cos[x]*Sin[x]
>
> functions:
>
> =9A Simplify[Sin[x]*Cos[x], ComplexityFunction ->
> =9A =9A =9A (LeafCount[#1] + 10*Count[#1, _Cos,
> =9A =9A =9A =9A =9A =9A =9A =9AInfinity] & )]
> =9A (1/2)*Sin[2*x]
This is very useful example for me. Thank you. Now it is clear.
Alexey Popkov
wrote:
> Alexey Popkov wrote:
>
> <snip>
>
> > Recently I also have found another strange bug in Simplfy (not so
> > dangerous):
> > FullSimplify[Sin[x]*Cos[x]]
> > gives Sin[x]*Cos[x] instead Sin[2*x]/2. The workaround is
> > FullSimplify[2*Sin[x]*Cos[x]]/2.
>
>
> This is not a bug, indeed. As a rule of thumb, *FullSimplify* tries to
> minimize the leaf count of the expression.
>
> For the case above, the original expression sin(x)cos(x) has a leaf
> count of 5 whereas the trigonometric identity sin(2x)/2 has a leaf count
> of 8. Therefore, *FullSimplify* returns the original form sin(x)cos(x)
> since it is deemed as simpler than sin(2x)/2 w.r.t. the lead count of
> each expression.
>
> Note that, in general, you can modify/tweak this default behavior to
> suit your needs by witting your own *ComplexityFunction*. However, when
> dealing with trigonometric expressions (especially when looking for some
> trigonometric identities) it is usually better and less cumbersome to
> use *TrigReduce* and the like (*TrigExpand*, *TrigFactor*, etc.).
>
[x] *)
> % // LeafCount (* returns =
5 *)
> TrigReduce[Sin[x]*Cos[x]] (* returns 1/2 Sin[=
2 x] *)
> % // LeafCount (* returns =
8 *)
> LeafCount[Cosh[x] - Sinh[x]] (* returns 7 =
*)
> FullSimplify[Cosh[x] - Sinh[x]] (* returns E^-x =
*)
> % // LeafCount (* returns =
5 *)
>
> Best regards,
> -- Jean-Marc
Big thanks! I did not understand this from the documentation. But now
this become clear.
David W.Cantrell
That's not the reason. Rather, it's because we performed the _integration_
with the assumption that m==n. (Note that if the integration had been done
without that assumption and then that result had been simplified with the
assumption, we would have gotten Indeterminate.)
> So, with my interpretation (different symbols are always different
> quantities unless stated otherwise) all is well.
Not in my opinion. If both m and n are 0, then obviously the value of the
integral must be 0, rather than L/2. (BTW, I had not noted that fact in my
previous response to Kevin.)
In my previous post, I gave a result which is valid for all real values of
the parameters:
L/2 (Sinc[(m - n) Pi] - Sinc[(m + n) Pi])
David W. Cantrell
Andrzej Kozlowski
things I wrote were clearly wrong. Here is a more considered response.
On 12 Apr 2008, at 08:17, Andrzej Kozlowski wrote:
>
> On 12 Apr 2008, at 07:27, David W. Cantrell wrote:
>> [Message also posted to: comp.soft-sys.math.mathematica]
> Yes, of course I realized that. In fact, note that
>
> Simplify[Integrate[Sin[(m*Pi*x)/L]*Sin[(n*Pi*x)/L], {x, 0, L}],
> Assumptions -> Element[m | n, Integers] && m == n]
>
> returns Indeterminate while
>
> Assuming[Element[m | n, Integers] && m == n,
> Simplify[Integrate[Sin[(m*Pi*x)/L]*Sin[(n*Pi*x)/L], {x, 0, L}]]]
>
> returns L/2.
>
> I did not mention this because I did not think it was relevant to
> the point I was making, which applies equally well (or equally
> badly) to Integrate and to Simplify. The point was that general
> principle that all distinct symbols represent distinct entities
> unless stated otherwise no logical problems arise. (By the way, this
> can actually be given a formal mathematical proof). However, I have
> to admit that Mathematica does not actually follow this principle -
> in fact it is kind of erratic about it.
I would like to add that this issue involves a certain basic
distinction between symbolic algebra (as performed by a computer) and
mathematics as practiced by humans. The meaning of every
"statement" (program) in computer algebra (unlike most statements in
mathematics) is "operational", in the sense that it involves a
definite order in which a certian operations are performed, and quite
often different orders will lead to different resulst. In mathematics
this issue is usually ignored as there is usually a "natural" or
"canonical" order which is not made explicit. As an example consider
the problem of simplifying
Integrate[Sin[(m*Pi*x)/L]*Sin[(n*Pi*x)/L], {x, 0, L}]
under the assumption that m and n are equal integers. "Operationally"
this can have two distinct meaning. One is: we assume first that m and
n are integers and simplify then Integrate the resulting expression.
In other words:
Simplify[Sin[(m*Pi*x)/L]*Sin[(n*Pi*x)/L],
Assumptions -> Element[m | n, Integers] && m == n]
Sin[(n*Pi*x)/L]^2
Integrate[%, {x, 0, L}, Assumptions ->
Element[ n, Integers] ]
L/2
The other: we integrate the given expression and then simplify the
answer with the given assumptions. In other words:
Integrate[Sin[(m*Pi*x)/L]*Sin[(n*Pi*x)/L], {x, 0, L}]
(L*n*Cos[n*Pi]*Sin[m*Pi] - L*m*Cos[m*Pi]*Sin[n*Pi])/
(m^2*Pi - n^2*Pi)
Simplify[%, Assumptions -> Element[m | n, Integers] && m == n]
Indeterminate
Ignoring for the time being the case m==n==0 (to which I will return
below) both of the above are quite correct from the "operational"
point of view, but only the first appraoch corresponds to the usual
meaning of "assuming..." in mathematics. In most cases, however, the
different operational orders will lead to the same outcome and the
issue which order to choose will be decided by considerations of
computational efficiency. I don't this issue can be completely avoided
in computer algebra but as long as one is aware of it, it should not
cause serious problems.
>
>>
>>
>>> So, with my interpretation (different symbols are always different
>>> quantities unless stated otherwise) all is well.
>>
>> Not in my opinion. If both m and n are 0, then obviously the value
>> of the
>> integral must be 0, rather than L/2. (BTW, I had not noted that
>> fact in my
>> previous response to Kevin.)
>
> What do you mean? I wrote that if we accept the convention that
> distinct symbols never represent the same quantity (unless
> explicitely stated that they do) then both m and n can't be 0.
> Opinion has nothing to do with that.
I wrote the above too quickly and I was clearly wrong (I did not
notice you were referring to the n==m case). You are quite right, this
time even my principle does not apply. So, to be strictly logical
and consistent here, there seem to be only three choices: to return
your answer (using Sinc), to return any answer at all (as Kevin
suggested) or to return a conditional answer (from Integrate). As I
wrote below, I think the first solution, although very attractive,
will not solve the general problem. I am inlcined to think that in
this case Integrate ought to return a conditional answer (If[m!
=0,...]) since (unlike Simplify) it does some time return conditional
answers. As I already indicated, I don't think that the "generic
parameters" argument is logically fully satisfactory, although its not
a bad guide to the actual practice.
Andrzej Kozlowski
>
>
>
>>
>>
>> In my previous post, I gave a result which is valid for all real
>> values of
>> the parameters:
>>
>> L/2 (Sinc[(m - n) Pi] - Sinc[(m + n) Pi])
>
>
> This is true but it deal with just the one single case of the
> function Sin. One can certainly come up with other cases where a
> similar problem appears not involving Sin so even if Mathematica
> returned this resut it would hardly deal with the wider problem.
>
> In any case, the problem is only one of formal interpretation - in
> practice it is easy to get around it if one is aware of how it comes
> about.
>
> Andrzej Kozlowski
Andrzej Kozlowski
Sinc does not solve the general problem here is a slightly different
example:
Simplify[Integrate[Exp[(2 m*I *Pi*x)/L]*Exp[(2 n*Pi*I*x)/L], {x, 0,
L}],
Assumptions -> Element[m | n, Integers]]
0
Simplify[Integrate[Exp[(m*I*Pi*x)/L]*
Exp[(n*Pi*I*x)/L], {x, 0, L}],
Assumptions -> Element[m | n, Integers] &&
m == -n]
Indeterminate
Simplify[Integrate[Exp[(0*I *Pi*x)/L]*Exp[(0*Pi*I*x)/L], {x, 0, L}]]
L
There are certainly lots of others of this kind. I don't see a panacea
for all of them.
Andrzej Kozlowski
> answer (If[m!=0,...]) since (unlike Simplify) it does some time
David W. Cantrell
> Just to demonstrate my assertion that returning the answer in terms
> of Sinc does not solve the general problem
> here is a slightly different example:
>
> Simplify[Integrate[Exp[(2 m*I *Pi*x)/L]*Exp[(2 n*Pi*I*x)/L],
> {x, 0, L}], Assumptions -> Element[m | n, Integers]]
> 0
>
> Assumptions -> Element[m | n, Integers] && m == -n]
> Indeterminate
>
> Simplify[Integrate[Exp[(0*I *Pi*x)/L]*Exp[(0*Pi*I*x)/L], {x, 0, L}]]
> L
>
> There are certainly lots of others of this kind. I don't see a
> panacea for all of them.
I never claimed to have a panacea. Nonetheless, returning an answer in
terms of Sinc certainly _does_ work for your "slightly different
example". (BTW, I'm quite puzzled that you claim to provide an example
showing that returning an answer in terms of Sinc does not help, but
yet you never actually show what an appropriate answer in terms of
Sinc would be!)
Your example seems, at least to my eye, to be needlessly complicated.
The problem which lies at its heart is simply that
In[6]:= Integrate[Exp[r x], x]
Out[6]= E^(r*x)/r
is not valid when r happens to be 0, for then we should instead have
In[7]:= Integrate[Exp[0 x], x]
Out[7]= x
But, using Sinc, it's easy to give an antiderivative for Exp[r x]
which is valid even when r happens to be 0:
x (Sinc[I r x] + r x/2 Sinc[I r x/2]^2)
Of course, that antiderivative can then be used to get an answer for
your specific example, namely, your first definite integral
Integrate[Exp[(2 m*I *Pi*x)/L]*Exp[(2 n*Pi*I*x)/L], {x, 0, L}]
is
L*(Sinc[2*(m + n)*Pi] + I*(m + n)*Pi*Sinc[(m + n)*Pi]^2)
So again, Sinc was helpful. But of course, many examples
could be given in which Sinc would be of no help.
David W. Cantrell
Andrzej Kozlowski
this issue. I manufactured the example essentilally by replacing Sin
by Exp, and of course I should have remembered that as these
functions are closely related one very likely probably manufacture a
siutbale anti-derivative in terms of Sinc.
But my purpose was to demonstrate how easily one can generate examples
of this kind. In order for your proposed solution to be really useful
what you would need to do is
1) construct a general algorithm for expressing at least a wide class
of such anti-derivatives in tems of Sinc (and parhaps other related
functions)
2) show how to combine this algorithm with the Risch algorithm used in
all current CAS systems for evaluating indefinite integrals.
Unless you or someone can deal with both of these problems (none of
which seems very easy to me but then this is not my field and I have
not given the issue more time than it takes ot write this sort of
message), then even if you write many more posts to the MathGroup on
the virues of Sinc and related topics (in addition to the large number
that you have already written) they will all remain just curiosities
without any practical impact.
Andrzej Kozlowski
Alexey Popkov
> I have the following rather simple integral of two sines, which should
> evaluate to zero if m is not equal to n and to L/2 if they are the same.
Try the following:
Integrate[Exp[(a - 1)*x], x] /. a -> 1
Integrate[Cos[(a - 1)*x], x] /. a -> 1
Integrate[(a - 1)^x, {x, -1, 0}] /. a -> 1
Integrate[Cos[a x]/Sin[x], x] /. a -> 1
There is the ONE underlying BUG! In some complicated cases this bug
may result in random partial answers.
http://forum.ru-board.com/topic.cgi?forum=5&topic=10291&start=80#9
Alexey Popkov
> Simplify does not return conditional answers (in the form If[..]) and
> I don't think it would be reasonable to expect it to do so.
The problem statement was initially wrong. The problem not in Simplify
but in Integrate!
Integrate may and MUST return conditions as it do it in other cases:
In[1]:= Integrate[Exp[-a x^2], {x, 0, Infinity}]
Out[1]= If[Re[a] > 0, Sqrt[Pi]/(2*Sqrt[a]), Integrate[E^(-(a*x^2)),
{x, 0, Infinity},
Assumptions -> Re[a] <= 0]]
But it does not do it in many other cases loosing some answers:
Daniel Lichtblau
>>evaluate to zero if m is not equal to n and to L/2 if they are the same.
>
>
> Integrate[Exp[(a - 1)*x], x] /. a -> 1
> Integrate[Cos[(a - 1)*x], x] /. a -> 1
> Integrate[(a - 1)^x, {x, -1, 0}] /. a -> 1
> Integrate[Cos[a x]/Sin[x], x] /. a -> 1
>
> There is the ONE underlying BUG! In some complicated cases this bug
> may result in random partial answers.
>
Removing the replacements, here are the Integrate results.
In[17]:= InputForm[Integrate[Exp[(a - 1)*x], x]]
Out[17]//InputForm= E^((-1 + a)*x)/(-1 + a)
In[18]:= InputForm[Integrate[Cos[(a - 1)*x], x]]
Out[18]//InputForm= Sin[(-1 + a)*x]/(-1 + a)
In[19]:= InputForm[Integrate[(a - 1)^x, {x, -1, 0}]]
Out[19]//InputForm= (-2 + a)/((-1 + a)*Log[-1 + a])
In[20]:= InputForm[Integrate[Cos[a*x]/Sin[x], x]]
Out[20]//InputForm=
((1 + a)*Hypergeometric2F1[1/2 - a/2, 1, 3/2 - a/2, E^((2*I)*x)] -
(-1 + a)*E^((2*I)*a*x)*Hypergeometric2F1[(1 + a)/2, 1, (3 + a)/2,
E^((2*I)*x)])/((-1 + a^2)*E^(I*(-1 + a)*x))
As far as I am aware thse are correct. What is the bug?
Daniel Lichtblau
Wolfram Research
Bill Rowe
>Try the following:
>Integrate[Exp[(a - 1)*x], x] /. a -> 1
>Integrate[Cos[(a - 1)*x], x] /. a -> 1
>Integrate[(a - 1)^x, {x, -1, 0}] /. a -> 1
>Integrate[Cos[a x]/Sin[x], x] /. a -> 1
>There is the ONE underlying BUG!
There is no bug here. Each of the integrals you do above result
in an expression divided by (a-1). The replacement rule simply
substitutes 1 for a everywhere. Consequently, the denominator of
each integral evaluates to 0 and Mathematica returns either
Indeterminate or ComplexInfinity as it should.
Where you expecting a to be replaced by 1 before the integration
was done? If so, the syntax should be written
Integrate[f/.a->1,x]
Or perhaps you were expecting Mathematica to simplify the
results of the integral before replacing a with 1. If so, you
need either
FullSimplify[Integrate[f,x]]/.a->1
or
Simplify[Integrate[f,x]]/.a->1
However, neither of these are guaranteed to remove the
singularity. So, these may result in exactly what you got.
Alexey Popkov
I am expecting to get all partial answers or at least an answer with
conditions!
On 11 =C1=D0=D2, 09:42, dh <d...@metrohm.ch> wrote:
>In the manual one finds:
> "For indefinite integrals, Integrate tries to find results that are
> correct for almost all values of parameters."
This note is located under "MORE INFORMATION" field in the reference
for Integrate. And this seems to be false... :( And for definite
integrals there is an option "GenerateConditions" that does not work
in the most cases (try it with example above:
int1 = Integrate[Sin[a*x/L]*Sin[x/L], {x, 0, L}, GenerateConditions ->
True]
int1 /. a -> 1
The answer is Indeterminate that is false! :(
).
Alexey Popkov
> Alexey Popkov wrote:
> > On Apr 10, 10:14 am, "Kevin J. McCann" <Kevin.McC...@umbc.edu> wrote:
>
>
> > Try the following:
> > Integrate[Exp[(a - 1)*x], x] /. a -> 1
> > Integrate[Cos[(a - 1)*x], x] /. a -> 1
> > Integrate[(a - 1)^x, {x, -1, 0}] /. a -> 1
> > Integrate[Cos[a x]/Sin[x], x] /. a -> 1
>
> > There is the ONE underlying BUG! In some complicated cases this bug
> > may result in random partial answers.
>
> >http://forum.ru-board.com/topic.cgi?forum=5&topic=10291&start=80#9
>
> Removing the replacements, here are the Integrate results.
>
> In[17]:= InputForm[Integrate[Exp[(a - 1)*x], x]]
> Out[17]//InputForm= E^((-1 + a)*x)/(-1 + a)
>
> In[18]:= InputForm[Integrate[Cos[(a - 1)*x], x]]
> Out[18]//InputForm= Sin[(-1 + a)*x]/(-1 + a)
>
> In[19]:= InputForm[Integrate[(a - 1)^x, {x, -1, 0}]]
> Out[19]//InputForm= (-2 + a)/((-1 + a)*Log[-1 + a])
>
> In[20]:= InputForm[Integrate[Cos[a*x]/Sin[x], x]]
> Out[20]//InputForm=
> ((1 + a)*Hypergeometric2F1[1/2 - a/2, 1, 3/2 - a/2, E^((2*I)*x)] -
> =9A =9A(-1 + a)*E^((2*I)*a*x)*Hypergeometric2F1[(1 + a)/2, 1, (3 + a)/2,
> =9A =9A =9AE^((2*I)*x)])/((-1 + a^2)*E^(I*(-1 + a)*x))
>
> As far as I am aware thse are correct. What is the bug?
>
> Daniel Lichtblau
> Wolfram Research
The above answers are correct only if "a" is not equal to 1. Answers
with a=1 are lost!
And code:
int1 = Integrate[Cos[a*x]/Sin[x], x];
int1 /. a -> 1
MUST give us answer equal to
int2 = Integrate[Cos[x]/Sin[x], x]
But the first answer is invalid in this simple case... :(
I should emphasize that in some complicated cases this BUG may result
in random partial answers!
And the lost answer in the above-mentioned case (by Kevin J. McCann)
is already very dangerous in spite of the fact that this partial
answer is still not random (because in this relatively simple case
there are only 2 partial answers):
int1 = Integrate[Sin[a*x/L]*Sin[x/L], {x, 0, L}]
int1 /. a -> 1
int2 = Integrate[Sin[x/L]*Sin[x/L], {x, 0, L}]
One can represent how it will be, when 3 or more partial answers will
exist!
Andrzej Kozlowski
Concerning indefinite integrals: I suggest you look at any book on
algebraic integration and the Risch algorithm. One possibility is the
famous and fundamental monograph: "On the integration of algebraic
functions" by John Davenport (Springer 1981) (there is a Russian
translation Mir 1985). You will find that in this book and in all
others the so called Risch algorithm is used and this algorithm works
in a certain function field. Both inputs and outputs are elements of a
function field and values of functions at special points do not enter
at any stage of the algorithm, therefore you cannot expect that
Integrate[Exp[(a - 1)*x], x] /. a -> 1
will give the same answer as
Unevaluated[Integrate[Exp[(a - 1)*x], x]] /. a -> 1
x
If you want the latter answer use the latter input.
By the way, the very same approach approach is implemented in every
computer algebra system in existence.
In the case of definite integration the situation may vary, because
the answer provided by the Risch algorithm is then post-processed, so
sometimes some account of special values can be made. But in any
case, you cannot in general expect that Unevaluated[f[x,y]]/.y->a
will return the same value as f[x,y]/.y->a, for many "functions" f
which use algorithms valid in some function algebras. Whether they do
so or not will depend on post-processing of the answers returned by
algebraic algorithms and whether such post-processing can deal with
special values of parameters will depend on considerations such as how
costly it is in terms of processing time to try to check for singular
values etc.
There is absolutely no point claiming that you have found a bug when
you do not understand the existing algorithms (which you obviously do
not), and such things as the cost in computing time of implementing an
approach that would not suffer from this "bug", etc. And there is also
no point at all arguing with with a developer who tells you that as
far as he is concerned there is no bug. It is, so to speak, a "take it
or leave it" situation.
Andrzej Kozlowski
On 15 Apr 2008, at 19:51, Alexey Popkov wrote:
> On 15 =C1=D0=D2, 13:51, Daniel Lichtblau <d...@wolfram.com> wrote:
>> Alexey Popkov wrote:
>>> On Apr 10, 10:14 am, "Kevin J. McCann" <Kevin.McC...@umbc.edu>
>>> wrote:
>>
>>>> I have the following rather simple integral of two sines, which
>>>> should
>>>> evaluate to zero if m is not equal to n and to L/2 if they are
Daniel Lichtblau
> On 15 =C1=D0=D2, 13:51, Daniel Lichtblau <d...@wolfram.com> wrote:
>
>>Alexey Popkov wrote:
>>
>>>On Apr 10, 10:14 am, "Kevin J. McCann" <Kevin.McC...@umbc.edu> wrote:
>>
>
>
>>>Try the following:
>>>Integrate[Exp[(a - 1)*x], x] /. a -> 1
>>>Integrate[Cos[(a - 1)*x], x] /. a -> 1
>>>Integrate[(a - 1)^x, {x, -1, 0}] /. a -> 1
>>>Integrate[Cos[a x]/Sin[x], x] /. a -> 1
>>
>>>There is the ONE underlying BUG! In some complicated cases this bug
>>>may result in random partial answers.
>>
>>>http://forum.ru-board.com/topic.cgi?forum=5&topic=10291&start=80#9
>>
>>Removing the replacements, here are the Integrate results.
>>
>>In[17]:= InputForm[Integrate[Exp[(a - 1)*x], x]]
>>Out[17]//InputForm= E^((-1 + a)*x)/(-1 + a)
>>As far as I am aware thse are correct. What is the bug?
>>
>>Daniel Lichtblau
>>Wolfram Research
>
>
> The above answers are correct only if "a" is not equal to 1. Answers
> with a=1 are lost!
>
> And code:
>
> int1 = Integrate[Cos[a*x]/Sin[x], x];
> int1 /. a -> 1
>
> MUST give us answer equal to
>
> int2 = Integrate[Cos[x]/Sin[x], x]
Capitalization notwithstanding, it need not do any such thing. Integrate
should give a generic result that behaves sensibly in the limit as a->1
from whatever path is specified to Limit. This is similar to the
situation of
In[18]:= InputForm[solns = x /. Solve[a*x^2 + x == 1, x]]
Out[18]//InputForm= {(-1 - Sqrt[1 + 4*a])/(2*a),
(-1 + Sqrt[1 + 4*a])/(2*a)}
In[20]:= Limit[solns, a->0]
Out[20]= {-Infinity, 1}
Note that a blind substitution of a->0 will not give "nice" results.
In[21]:= solns /. a->0
1
Power::infy: Infinite expression - encountered.
0
1
Power::infy: Infinite expression - encountered.
0
Infinity::indet: Indeterminate expression 0 ComplexInfinity encountered.
Out[21]= {ComplexInfinity, Indeterminate}
> But the first answer is invalid in this simple case... :(
>
> I should emphasize that in some complicated cases this BUG may result
> in random partial answers!
I'll emphasize that this is not a bug; it's the way Integrate is
intended to work in Mathematica. An antiderivative of a function that
depends on parameters can be invalid for some values of those
parameters. Provided we are talking about analytic functions (things
that can be said to have antiderivatives in the usual meaning of the
term), the "bad set" will have measure zero.
Daniel Lichtblau
Wolfram Research
Bhuvanesh
> > "For indefinite integrals, Integrate tries to find results that are
> > correct for almost all values of parameters."
>
> This note is located under "MORE INFORMATION" field in the reference
> for Integrate. And this seems to be false... :( And for definite
> integrals there is an option "GenerateConditions" that does not work
> in the most cases (try it with example above:
> int1 = Integrate[Sin[a*x/L]*Sin[x/L], {x, 0, L}, GenerateConditions ->
> True]
> int1 /. a -> 1
> The answer is Indeterminate that is false! :(
> ).
Again, the given behavior is not a bug. It is similar to Mathematica
returning x^(n+1)/(n+1) for the indefinite integral of x^n, or
simplifying x/x to 1. You missed the part in the manual where it says
that Integrate tries to find results that are correct for *almost all*
(emphasis added) values of parameters.
Bhuvanesh,
Wolfram Research
Bill Rowe
>And code:
>int1 = Integrate[Cos[a*x]/Sin[x], x]; int1 /. a -> 1
>MUST give us answer equal to
>int2 = Integrate[Cos[x]/Sin[x], x]
Mathematica simply doesn't work this way.
If you do Integrate[Cos[a x]/Sin[x],x] you will see a fairly
complex expression. I assume this expression is valid and can be
simplified to Log[Sin[x]] when a is 1 with the right
transformations. But it is far from obvious to me what
transformations are required. And Mathematica does not attempt
to simplify this expression.
Once you get this result, the replacement rule simply
substitutes 1 for a every where and evaluates. This simple
process results in division by 0.
There are two ways to avoid this problem. One would be to find
the set of transformations that reduce the expression to Log[Sin[x]].
The other is to re-write the problem as:
Integrate[Cos[a x]/Sin[x]/.a->1, x]
Despite the fact, Mathematica does not get the result you
desire, this is not a bug. Mathematica is working as intended.
So, you have a choice. Either accept this and figure out how to
use Mathematica as it is or find some other tool that works more
like you want.
Alexey Popkov
>
> >>Alexey Popkov wrote:
>
> >>>On Apr 10, 10:14 am, "Kevin J. McCann" <Kevin.McC...@umbc.edu> wrote:
>
> >>>>I have the following rather simple integral of two sines, which should=
> >>>>evaluate to zero if m is not equal to n and to L/2 if they are the sam=
e.=
>
> >>>Try the following:
> >>>Integrate[Exp[(a - 1)*x], x] /. a -> 1
> >>>Integrate[Cos[(a - 1)*x], x] /. a -> 1
> >>>Integrate[(a - 1)^x, {x, -1, 0}] /. a -> 1
> >>>Integrate[Cos[a x]/Sin[x], x] /. a -> 1
>
> >>>There is the ONE underlying BUG! In some complicated cases this bug
> >>>may result in random partial answers.
>
> >>>http://forum.ru-board.com/topic.cgi?forum=5&topic=10291&start=80#=
9
>
> >>Removing the replacements, here are the Integrate results.
>
> >>In[17]:= InputForm[Integrate[Exp[(a - 1)*x], x]]
> >>Out[17]//InputForm= E^((-1 + a)*x)/(-1 + a)
> >> [...]
> >>As far as I am aware thse are correct. What is the bug?
>
> >>Daniel Lichtblau
> >>Wolfram Research
>
> > The above answers are correct only if "a" is not equal to 1. Answers
> > with a=1 are lost!
>
> > And code:
>
> > int1 = Integrate[Cos[a*x]/Sin[x], x];
> > int1 /. a -> 1
>
> > MUST give us answer equal to
>
> > int2 = Integrate[Cos[x]/Sin[x], x]
>
Well. But how I can get the partial answer for the case a=1 with
Limit?
I have tried the foolowing code:
In[1]:= Limit[Integrate[Cos[a*z]/Sin[z],z],a->1]
Out[1]= \[Infinity]
In[2]:= Limit[Integrate[Exp[a*z]*Sinh[z],z],a->1]
Out[2]= -\[Infinity]
In[3]:= Limit[Integrate[Exp[z]*Sinh[a z],z],a->1]
Out[3]= E^z DirectedInfinity[E^(-I*Im[z])]
In[4]:= Limit[Integrate[Exp[(a-1)*x],x],a->1]
Out[4]= \[Infinity]
All results are incorrect!
As I understand, Integrate does not give a generic result that behaves
sensibly in the limit as a->1!
Daniel Lichtblau
> [...]
>>Capitalization notwithstanding, it need not do any such thing. Integrate
>>should give a generic result that behaves sensibly in the limit as a->1
>
>>from whatever path is specified to Limit. This is similar to the
>
>>situation of
>
>
>>In[18]:= InputForm[solns = x /. Solve[a*x^2 + x == 1, x]]
>>Out[18]//InputForm= {(-1 - Sqrt[1 + 4*a])/(2*a),
>> (-1 + Sqrt[1 + 4*a])/(2*a)}
>>
>>In[20]:= Limit[solns, a->0]
>>Out[20]= {-Infinity, 1}
>>
>>Note that a blind substitution of a->0 will not give "nice" results.
>
>
> Well. But how I can get the partial answer for the case a=1 with
> Limit?
> I have tried the foolowing code:
> In[1]:= Limit[Integrate[Cos[a*z]/Sin[z],z],a->1]
> Out[1]= \[Infinity]
> In[2]:= Limit[Integrate[Exp[a*z]*Sinh[z],z],a->1]
> Out[2]= -\[Infinity]
> In[3]:= Limit[Integrate[Exp[z]*Sinh[a z],z],a->1]
> Out[3]= E^z DirectedInfinity[E^(-I*Im[z])]
> In[4]:= Limit[Integrate[Exp[(a-1)*x],x],a->1]
> Out[4]= \[Infinity]
> All results are incorrect!
> As I understand, Integrate does not give a generic result that behaves
> sensibly in the limit as a->1!
Sorry, I should have stated the situation more clearly.
Yes, the antiderivatives you see have singularities at the parameter
value in question (in all cases, when a is 1). Hence the results you
show above. What I should have said is that one can get these
singularities to cancel, if using the parametrized antiderivatives to
obtain definite integrals a la Newton-Leibniz. Here is a standard simple
example (modified slightly so as to have a->1 as the bad value).
In[22]:= InputForm[i1 = Integrate[x^(-a),x]]
Out[22]//InputForm= x^(1 - a)/(1 - a)
Certainly it blows up as a->1.
In[23]:= Limit[i1, a->1]
Out[23]= -Infinity
In[24]:= Limit[i1, a->1, Direction->1]
Out[24]= Infinity
But if we take a pair of values for x, say 2 and 3, to evaluate the
definite integral, we in fact get the expected/desired logarithm result
in the limit as a->1 (and independent of direction).
In[27]:= InputForm[Limit[(i1/.x->3)-(i1/.x->2), a->1]]
Out[27]//InputForm= Log[3/2]
In[28]:= InputForm[Limit[(i1/.x->3)-(i1/.x->2), a->1, Direction->1]]
Out[28]//InputForm= Log[3/2]
To see that this really is reproducing the Fundamental Theorem of
Calculus result (or at least doing a heckuva job to fool me), I'll show
this instead as a definite integral from x0 to x.
In[29]:= InputForm[Limit[i1 - (i1/.x->x0), a->1]]
Out[29]//InputForm= Log[x] - Log[x0]
I believe most of your examples will also behave fine when processed in
this way. The Cos[a*z]/Sin[z] integrand might be an exception, but that
indicates a limitation of Limit rather than a bug in Integrate.
Depending on whether you give symbolic (z,z0) or exact numeric (3,2)
input to Limit it either returns a complicated, but seemingly correct
result, or else unevaluated.
Daniel Lichtblau
Wolfram Research
Alexey Popkov
Thank you for the explanation. Now I understand. But I think that the
same way as there is an alternative to Solve (the function Reduce)
that carefully keeps track for all conditions for the all partial
answers, there should be also an alternative to Integrate that also
keeps track for conditions and gives the all partial answers! I am
grieved deeply that the alternative does not exists for this case!
In[1]:= Reduce[1/(a*x)==1,x]
Out[1]= a!=0&&x==1/a
This example is the true mathematics!
Andrzej Kozlowski
Indeed. However, there would be two problems. First, someone would
have to devise suitable algorithms and implement them. This may not be
totally impossible, but it would certainly take a lot of effort. But
then, we would see the second problem. This "ideal integrate "would
run for ever on almost any non-trivial problem. You would get nice
"mathematical" answers to trivial ones, which would make you feel
good, and no answers to non-trivial ones, which would probably make
you a annoyed enough to complain (to the MathGroup?).
Would that be a good way to use the time and effort of programmers and
your own money?
As for Reduce - you should try it a little more on harder problems
than the one you have just presented. It uses some very beautiful and
powerful algorithms like Cylindrical Algebraic Decomposition but they
have exponential or in this case "double exponential" complexity (in
the number of variables) so if you it try on something with more than
3 variables involved you will see what I mean. Given the choice
between a program that does everything in the spirit of "true
mathematics" but can only sole trivial problems that can be done by
hand and one that gives only "generic" solutions but can deal with
cases that would take you a hundred years to do by hand, which one
would you choose?
Andrzej Kozlowski
Alexey Popkov
I do not see the reason why in the case of Integrate keeping track for the conditions will take more time than in the case of Reduce. As I understand it is just the same or something like.
Andrzej Kozlowski
No, because the formulas that Integrate deals with are very often the
kind Reduce cannot deal at all with (Reduce can basically only manage
algebraic equations and inequalities and those reducible to algebraic
ones. Integrate often deals with transcendental functions or, what's
worse, composites of transcendental and algebraic ones). If you wanted
Integrate to keep track of all conditions, it would have to try to
solve equations to check for zeros in the denominator, common zeros in
the numerator and the denominator and such like, and it would have to
do it not just in the simple cases (like your example) but in all
cases. But in the vast majority of cases it can't do anything of the
sort. As an illustration, just take one of your examples:
p = Integrate[Sin[a x]/Cos[x], x];
Reduce[Numerator[p]==0,a]
Reduce[Numerator[p] == 0, a]
"This system cannot be solved with the methods available to
Reduce. Reduce[(-(a + 1))*Hypergeometric2F1[1/2 - a/2, 1,
3/2 - a/2, -E^(2*I*x)] - (a - 1)*E^(2*I*a*x)*
Hypergeometric2F1[(a + 1)/2, 1, (a + 3)/2,
-E^(2*I*x)] == 0, a]
And even in the purely algebraic cases Reduce can easily take for
ever. Or consider this:
Reduce[x^3 + Sin[x] == 0, x]
During evaluation of In[34]:= Reduce::"nsmet" : "This system cannot
be solved with the methods available to Reduce"
even though anyone can easily see that 0 is a solution (but Reduce is
not allowed to return an incomplete solution).
The problems with you kind of Integrate would involve all the above
and worse.
Adnrzej Kozlowski
Alexey Popkov
> And even in the purely algebraic cases Reduce can easily take for
> ever. Or consider this:
>
> Reduce[x^3 + Sin[x] == 0, x]
>
> During evaluation of In[34]:= Reduce::"nsmet" : "This system cannot
> be solved with the methods available to Reduce"
>
> even though anyone can easily see that 0 is a solution (but Reduce is
> not allowed to return an incomplete solution).
I was surprised a bit. It is sad that even if I specify the Real
domain I may not give the only possible answer x=0:
Reduce[x + Sin[x] == 0, x, Reals]
Solve[x + Sin[x] == 0, x, Reals]
Now I understand the depth of the problem.
But speaking about Integrate, is it really necessarily to perform
Reduce[] on each step? The problem is to find the singularities on the
parameters of the argument function (I mean such values of the
parameters those degenerate the argument function). After this we
should keep track on arising new conditions on each step. It does not
mean to use Reduce. We need only understand what we really do and know
about limitations. As I think this is not so much complicated task and
may be fully implemented in Mathematica (if it is not implemented
already). On the final result we may need perform searching for the
singularities again - but only for checking the result!
But as I see first of all Wolfram Research should extend Reduce[] for
working with trigonometric functions. This is that we should wait for
nearest-future version of Mathematica. If we can not expect this -
what for we should pay money?
Daniel Lichtblau
>>ever. Or consider this:
>>
>> Reduce[x^3 + Sin[x] == 0, x]
>>
>>During evaluation of In[34]:= Reduce::"nsmet" : "This system cannot
>>be solved with the methods available to Reduce"
>>
>>even though anyone can easily see that 0 is a solution (but Reduce is
>>not allowed to return an incomplete solution).
>
>
>
> I was surprised a bit. It is sad that even if I specify the Real
> domain I may not give the only possible answer x=0:
> Reduce[x + Sin[x] == 0, x, Reals]
> Solve[x + Sin[x] == 0, x, Reals]
>
> Now I understand the depth of the problem.
>
> But speaking about Integrate, is it really necessarily to perform
> Reduce[] on each step? The problem is to find the singularities on the
> parameters of the argument function (I mean such values of the
> parameters those degenerate the argument function).
Both integrand and indefinite integral might pose issues.
> After this we
> should keep track on arising new conditions on each step. It does not
> mean to use Reduce.
How else do you propose this might be done?
> We need only understand what we really do and know
> about limitations.
Here is a limitation. How does one figure out when, or where, a branch
cut is crossed, if teh functions involved contain parameters?
> As I think this is not so much complicated task and
> may be fully implemented in Mathematica (if it is not implemented
> already).
Umm, not to put too fine a point on things, but quite clearly you have
no experience with this. Suffice it to say that full analysis of
parametrized singularities for definite integrals is not implemented in
Mathematica already. Nor anywhere else. I suspect partial analysisof
such to be better developed in Mathematica than in other software, but I
cannot state that as a fact.
> On the final result we may need perform searching for the
> singularities again - but only for checking the result!
>
> But as I see first of all Wolfram Research should extend Reduce[] for
> working with trigonometric functions.
Reduce[] handles trigs (alone) just fine. The example above mixes
polynomial with trigonometric functions, of the same variable. handling
this is quite nontrivial.
> This is that we should wait for
> nearest-future version of Mathematica. If we can not expect this -
> what for we should pay money?
I am not aware of any existing software that does what I believe you are
requesting. That might give an indication that the algorithmic
technology required is not yet out there.
Daniel Lichtblau
Wolfram Research