MathGroup Archive 2008

[Date Index] [Thread Index] [Author Index]

Search the Archive

Re: Re: A Problem with Simplify

I can see no bugs here at all.

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

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... at> wrote:
>> Alexey Popkov wrote:
>>> On Apr 10, 10:14 am, "Kevin J. McCann" <Kevin.McC... at>  
>>> 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.=
>>> 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.
>> 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!
> On 11 =C1=D0=D2, 09:42, dh <d... at> 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! :(
> ).

  • Prev by Date: Re: Re: A Problem with Simplify
  • Next by Date: Re: Re: Re: Re: Player Pro and Packages
  • Previous by thread: Re: Re: A Problem with Simplify
  • Next by thread: Re: A Problem with Simplify