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>
- bad performance of Reduce (5.2)