MathGroup Archive 2008

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

Search the Archive

Re: Re: A Problem with Simplify

  • To: mathgroup at
  • Subject: [mg87962] Re: [mg87908] Re: A Problem with Simplify
  • From: Andrzej Kozlowski <akoz at>
  • Date: Mon, 21 Apr 2008 03:26:57 -0400 (EDT)
  • References: <>

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]
  "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

  • Prev by Date: Re: How to remove unneeded constraints
  • Next by Date: Tilted decimals - Mathematica 6
  • Previous by thread: Re: A Problem with Simplify
  • Next by thread: Re: A Problem with Simplify