[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
Prev by Date:
**Re: bad performance of Reduce (5.2)**
Next by Date:
**Re: Re: Fast interactive graphics**
Previous by thread:
**Re: bad performance of Reduce (5.2)**
Next by thread:
**Re: bad performance of Reduce (5.2)**
| |