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

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>