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

First note the answer that Mathematica 6.0 gives:

Reduce[Sin[ArcTan[z] + ArcTan[2*z]] == 1/Sqrt && 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) || z == (1/4)*(3 + Sqrt)

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)