Re: Re: A Problem with Simplify

*To*: mathgroup at smc.vnet.net*Subject*: [mg87705] Re: [mg87696] Re: A Problem with Simplify*From*: Andrzej Kozlowski <akoz at mimuw.edu.pl>*Date*: Wed, 16 Apr 2008 04:59:37 -0400 (EDT)*References*: <ftkb7f$a9m$1@smc.vnet.net> <200804140943.FAA08090@smc.vnet.net> <200804151051.GAA27987@smc.vnet.net>

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 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... at wolfram.com> wrote: >> Alexey Popkov wrote: >>> On Apr 10, 10:14 am, "Kevin J. McCann" <Kevin.McC... at 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 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 >> >> 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 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! :( > ). >

**References**:**Re: A Problem with Simplify***From:*Alexey Popkov <popkov@gmail.com>

**Re: A Problem with Simplify***From:*Alexey Popkov <popkov@gmail.com>

**Re: Re: A Problem with Simplify**

**Re: Re: Re: Re: Player Pro and Packages**

**Re: Re: A Problem with Simplify**

**Re: A Problem with Simplify**