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: A Problem with Simplify