Re: bad performance of Reduce (5.2)

*To*: mathgroup at smc.vnet.net*Subject*: [mg77800] Re: [mg77773] bad performance of Reduce (5.2)*From*: Andrzej Kozlowski <akoz at mimuw.edu.pl>*Date*: Sun, 17 Jun 2007 06:02:50 -0400 (EDT)*References*: <200706160734.DAA26018@smc.vnet.net> <938E1270-E45A-4BF5-B8DF-DF7012009225@mimuw.edu.pl>

On 16 Jun 2007, at 18:48, Andrzej Kozlowski wrote: > > 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 On second thoughts: there is probably not much point in testing the condition that Reduce "assumed" numerically because I am sure Reduce had already done so, and assumed tha tit holds precisely because it passed all numerical tests at its disposal. Nevertheless, I still think that the user should be able to access the full condition that has been assumed, for reasons that seem to me to obvious to need stating. Andrzej Kozlowski

**References**:**bad performance of Reduce (5.2)***From:*dimitris <dimmechan@yahoo.com>

**Re: bad performance of Reduce (5.2)**

**Re: Re: Fast interactive graphics**

**Re: bad performance of Reduce (5.2)**

**Re: bad performance of Reduce (5.2)**