Re: A strange bug in Solve

*To*: mathgroup at smc.vnet.net*Subject*: [mg24356] Re: A strange bug in Solve*From*: Andrzej Kozlowski <andrzej at tuins.ac.jp>*Date*: Sun, 9 Jul 2000 04:52:59 -0400 (EDT)*Sender*: owner-wri-mathgroup at wolfram.com

A couple of small additions to the earlier message. The natural question that arises is: what will happen if we use the option MakeRules->False in Solve? Well this is what happens: In[1]:= eqns = {2*Cos[2*t]*Cos[u/2] + Cos[t]*Sin[u/2] == 0, (Cos[u/2]*Sin[t])/2 - (Sin[2*t]*Sin[u/2])/2 == 0}; In[2]:= Solve[eqns, {t, u}, MakeRules -> False] Out[2]= {} Another point, we can quickly get the solutions in the form used by Solve (without using solrules) with: In[3]:= {ToRules[Reduce[eqns, {t, u}]]} Reduce::"ifun": "Inverse functions are being used by Reduce, so some solutions may not be found." Out[3]= 1 {{t -> 0, u -> 2 ArcCos[-(-------)]}, Sqrt[5] 1 Pi {t -> 0, u -> -2 ArcCos[-------]}, {t -> -(--), u -> -Pi}, Sqrt[5] 2 3 Sqrt[-] Pi 2 {t -> --, u -> Pi}, {t -> ArcCos[-(-------)], 2 2 3 u -> 2 ArcCos[-Sqrt[-]]}, 5 3 Sqrt[-] 2 3 {t -> ArcCos[-------], u -> 2 ArcCos[Sqrt[-]]}} 2 5 on 00.7.8 3:00 PM, Andrzej Kozlowski at andrzej at tuins.ac.jp wrote: > I have long ago learned to be careful when making claims about kernel bugs > in Mathematica, but this time I am pretty sure I have found a fairly serious > one, even though it looks rather strange. > > I asked Mathematica to solve a system of two trigonometric equations: > > In[1]:= > eqns = {2*Cos[2*t]*Cos[u/2] + Cos[t]*Sin[u/2] == 0, > (Cos[u/2]*Sin[t])/2 - (Sin[2*t]*Sin[u/2])/2 == 0}; > > To my surprise Solve returned the empty list (I knew these equations do have > solutions for geometric reasons): > > In[2]:= > Solve[eqns, {u, t}] > Out[2]= > {} > > I then tried Reduce, and guess what, it gave the right answers: > > In[3]:= > sols = Reduce[eqns, {u, t}] > From In[3]:= > Reduce::ifun: Inverse functions are being used by Reduce, so some solutions > may not be found. > Out[3]= > 1 1 > t == 0 && u == 2 ArcCos[-(-------)] || t == 0 && u == -2 ArcCos[-------] || > Sqrt[5] Sqrt[5] > > -Pi Pi > t == --- && u == -Pi || t == -- && u == Pi || > 2 2 > > 3 > -Sqrt[-] > 2 3 > t == ArcCos[--------] && u == 2 ArcCos[-Sqrt[-]] || > 2 5 > > 3 > Sqrt[-] > 2 3 > t == ArcCos[-------] && u == 2 ArcCos[Sqrt[-]] > 2 5 > > > We can check them as follows: > > solrules = sols /. {Or -> List, And -> List, Equal -> Rule}; > In[5]:= > FullSimplify[Unevaluated[eqns /. solrules]] > Out[5]= > {{True, True}, {True, True}, {True, True}, {True, True}, {True, True}, > {True, True}} > > Here one might ask: why did I need to define solrules? Why not use the > options MakeRules->True in Reduce? The answer is: try and see what happens! > > This is peculiar and rather unpleasant. When Solve returns an > ampty list it ought to mean that there are no generic solutions (although > solutions might exist for some particular values of the parameters). Reduce > is supposed to try to work out these special cases. However, the solutions > found by Reduce in this case are perfectly generic. Moreover, the > spectacular failure of Reduce[eqns, MakeRules->True] suggest than somehting > else than the difficulty of finding the solutions that is causing the > problem here. > > Andrzej Kozlowski > -- Andrzej Kozlowski Toyama International University JAPAN http://platon.c.u-tokyo.ac.jp/andrzej/ http://sigma.tuins.ac.jp/

**RE: Contour labeling**

**Re: Divisors**

**A strange bug in Solve**

**Re: A strange bug in Solve**