Re: Re: A Problem with Simplify
- To: mathgroup at smc.vnet.net
- Subject: [mg87962] Re: [mg87908] Re: A Problem with Simplify
- From: Andrzej Kozlowski <akoz at mimuw.edu.pl>
- Date: Mon, 21 Apr 2008 03:26:57 -0400 (EDT)
- References: <200804200351.XAA11379@smc.vnet.net>
On 20 Apr 2008, at 12:51, Alexey Popkov wrote:
>> 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
>>
>
> 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.
>
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
- References:
- Re: A Problem with Simplify
- From: Alexey Popkov <popkov@gmail.com>
- Re: A Problem with Simplify