MathGroup Archive 2007

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

Search the Archive

Re: bad performance of Reduce (5.2)

  • To: mathgroup at smc.vnet.net
  • Subject: [mg77789] Re: [mg77773] bad performance of Reduce (5.2)
  • From: Andrzej Kozlowski <akoz at mimuw.edu.pl>
  • Date: Sun, 17 Jun 2007 05:57:12 -0400 (EDT)
  • References: <200706160734.DAA26018@smc.vnet.net>

On 16 Jun 2007, at 16:34, dimitris wrote:

> Hello.
>
> $VersionNumer
> 5.2
>
> o=Sin[ArcTan[z] + ArcTan[2*z]] -1/Sqrt[2] ;
>
> The equation o=0 has two roots in the real positive axis
>
> Plot[Sin[ArcTan[z] + ArcTan[2*z]] - 1/Sqrt[2], {z, 0, 5}]
>
> In[1]:=
> Needs["NumericalMath`IntervalRoots`"]
>
> In[21]:=
> IntervalBisection[Sin[ArcTan[z] + ArcTan[2*z]] - 1/Sqrt[2], z,
> Interval[{0, 5}], 0.1]
> List @@ %
> (FindRoot[Sin[ArcTan[z] + ArcTan[2*z]] - 1/Sqrt[2] == 0, {z, #1[[1]],
> #1[[2]]}, WorkingPrecision -> 30,
>     PrecisionGoal -> 20] & ) /@ %
>
> Out[21]=
> Interval[{0.23437500000000014, 0.31250000000000033}, {1.71875,
> 1.7968750000000009}]
>
> Out[22]=
> {{0.23437500000000014, 0.31250000000000033}, {1.71875,
> 1.7968750000000009}}
>
> Out[23]=
> {{z -> 0.28077640640441513745535298432248087547755357014`30.}, {z ->
> 1.780776406404415137455352463993519256286808059355`30.}}
>
> Solve returns the correct roots.
>
> In[21]:=
> Off[N::meprec]
>
> In[22]:=
> Solve[Sin[ArcTan[z] + ArcTan[2*z]] == 1/Sqrt[2], z]
> FullSimplify[Sin[ArcTan[z] + ArcTan[2*z]] == 1/Sqrt[2] /. %]
>
> Out[22]=
> {{z -> (1/4)*(-3 + Sqrt[17])}, {z -> (1/4)*(3 + Sqrt[17])}}
>
> Out[23]=
> {True, True}
>
> However, it is well known that Solve is not proper for equations like
> o=0.
>
> Let's use Reduce
>
> In[24]:=
> Reduce[Sin[ArcTan[z] + ArcTan[2*z]] == 1/Sqrt[2], z, Reals]
> (*ommited output*)
>
> Let's be more specifically!
>
> In[25]:=
> Reduce[Sin[ArcTan[z] + ArcTan[2*z]] == 1/Sqrt[2] && z > 0, z, Reals]
>
> Out[25]=
> ((-Pi + 4*ArcTan[(1/4)*(-3 + Sqrt[17])] + 4*ArcTan[(1/2)*(-3 +
> Sqrt[17])])/(8*Pi)   Integers && z == (1/4)*(-3 + Sqrt[17])) ||
>   ((-3*Pi + 4*ArcTan[(1/4)*(3 + Sqrt[17])] + 4*ArcTan[(1/2)*(3 +
> Sqrt[17])])/(8*Pi)   Integers && z == (1/4)*(3 + Sqrt[17]))
>
> The roots are correct but it appears a strange condition
>
> ((-Pi + 4*ArcTan[(1/4)*(-3 + Sqrt[17])] + 4*ArcTan[(1/2)*(-3 +
> Sqrt[17])])/(8*Pi)   Integers
>
> Any comments?
>
> Dimitris
>
>


First note the answer that Mathematica 6.0 gives:


Reduce[Sin[ArcTan[z] + ArcTan[2*z]] == 1/Sqrt[2] && z > 0, z, Reals]

Reduce::ztest:Unable to decide whether numeric quantities {1/4 (-4 
tan-1(1/4 (Power(<<2>>)-3))-4 tan-1(1/2 (Power(<<2>>)-3))+=B9),1/4 (-4 tan-1(1/4 (Power(<<2>>)+3))-4 tan-1(1/2 (Power(<<2>>)+3))+3 =B9)} are 
equal to zero. Assuming they are.

z == (1/4)*(-3 + Sqrt[17]) || z == (1/4)*(3 + Sqrt[17])

Do you like it better than the one 5.2 gives? Actually, I think it 
equivalent. The quantity about which 6.0 cannot decide if it is ==0 
or not is (probably)  the same as the one that appears in the answer 
to 5.2, where it it is assumed to be an integer. One way to read that 
answer is "if certain quantities are integers than the answers are 
given below".

I would not call this "bad performance", even when compared with 
Solve, unless you would prefer to get no answer at all from Reduce. 
Unlike Solve, Reduce is now allowed to give you a "special case" as 
an answer; it has to give a "complete answer" or none. But in this 
case, it would be able to give a complete answer if it could prove 
that certain quantities are integers (or zero in the case of 
Mathematica 6). Since Reduce cannot decide this, it has only two 
choices: either to return a message  "the methods available to Reduce 
are insufficient..." etc or to return some kind of conditional 
answer. It takes the second course, but the way it does it has been 
changed.  In version 5, the condition was inserted into the solution. 
In version 6, a different approach is used . A message appears saying 
that Reduce could not decide something so it is assuming it to be 
true and  is returning the complete  answer but valid only under this 
assumption.  I personally prefer the approach used by 5.2, because 
one can at least try to test the condition that Reduce assumed 
numerically. But in version 6 the condition is printed only as part 
of a message and because it is long, it is printed in an short form, 
so you actually can't tell exactly what the condition that is being 
assumed is. In fact, now that I started to think about it, it seems 
to me almost a bug, which I hope will be fixed. If some conditions 
are being assumed by Reduce they should be available to the user for 
farther testing. Is there a way to make Reduce print out this message 
in such a way that the complete condition can at least be seen and 
copied?

Andrzej Kozlowski


  • Prev by Date: Re: Help with formatting output
  • Next by Date: Re: bad performance of Reduce (5.2)
  • Previous by thread: bad performance of Reduce (5.2)
  • Next by thread: Re: bad performance of Reduce (5.2)