Re: simplification of 0/0 to 1?

*To*: mathgroup at smc.vnet.net*Subject*: [mg77550] Re: simplification of 0/0 to 1?*From*: dimitris <dimmechan at yahoo.com>*Date*: Wed, 13 Jun 2007 07:17:28 -0400 (EDT)*References*: <200706110822.EAA20741@smc.vnet.net><f4lbja$g2h$1@smc.vnet.net>

Thanks to the responses of Andrzej and Murray I learnt many new things and I am very happy for this! In fact, although I work a lot with simplifications, I never faced something similar. And I didn't imagine what a hidden zero could cause to the evaluator of Mathematica. What cause my original attitude, talking about a buggy perfomance was that the original expression was not a tricky one like In[40]:= (1 - Cos[a]^2 - Sin[a]^2)/(1 - Cos[a]^2 - Sin[a]^2) Out[40]= 1 but "a real expression". Note that how the evaluator behaves cannot be predictable! In[41]:= Simplify[(1 - Cos[a]^2 - Sin[a]^2)/(Cos[2*a] - Cos[a]^2 + Sin[a]^2)] Out[41]= Indeterminate Dimitris PS Daniel of WRI sent me privately another response which for obvious reasons I present here: ------------------------------------- (*Daniel Lichtblau reply*) ----------------------------------- Simplify tries a number of "standard" transformations (you've perhaps seen mention of this on MathGroup threads in past). Among them are Together and FactorSquareFree. Either of these will give that result for reasons that become clear when you apply them separately to numerator and denominator. oo = (Log[2]*Cos[Pi/12] - Log[2]*Sin[Pi/12] - 2*Cos[Pi/12] + 2*Sin[Pi/12] + Sqrt[2] + 2*Log[Cos[Pi/12] - Sin[Pi/12]]*Cos[Pi/12] - 2*Log[Cos[Pi/12] - Sin[Pi/12]]*Sin[Pi/12])/(Log[2]*Cos[Pi/12] - Log[2]*Sin[Pi/12] + 2*Log[Cos[Pi/12] - Sin[Pi/12]]*Cos[Pi/12] - 2*Log[Cos[Pi/12] - Sin[Pi/12]]*Sin[Pi/12]) nn = Numerator[oo]; dd = Denominator[oo]; In[5]:= Together[nn] Out[5]= (1/2)*(Sqrt[2]*Log[2] + 2*Sqrt[2]*Log[-((-1 + Sqrt[3])/(2*Sqrt[2])) + (1 + Sqrt[3])/(2*Sqrt[2])]) In[9]:= Together[dd] Out[9]= (1/2)*(Sqrt[2]*Log[2] + 2*Sqrt[2]*Log[-((-1 + Sqrt[3])/(2*Sqrt[2])) + (1 + Sqrt[3])/(2*Sqrt[2])]) In[22]:= FactorSquareFree[nn] Out[22]= (Log[2] + 2*Log[-((-1 + Sqrt[3])/(2*Sqrt[2])) + (1 + Sqrt[3])/(2*Sqrt[2])])/Sqrt[2] In[23]:= FactorSquareFree[dd] Out[23]= (Log[2] + 2*Log[-((-1 + Sqrt[3])/(2*Sqrt[2])) + (1 + Sqrt[3])/(2*Sqrt[2])])/Sqrt[2] At this point it is easy to see how the result of 1 comes about. The functions used by Simplify fail to recognize these are zero and the evaluator rules see that numerator and denominator are identical, hence result is 1. This is a manifestation of the so-called "hidden zero" problem, wherein bad transformations happen because intermediate results are zero, but sufficiently disguised as to escape identification as such. There is no coverall-cure (various papers in the literature explain this; see in particular work of Daniel Richardson). For some classes of expression one can hope to do better. That would certainly apply to the one of this example, where drilling harder into subexpressions uncovers the hidden zeros. In[21]:= MapAll[Simplify, oo] During evaluation of In[21]:= Power::infy: Infinite expression 1/0 \ encountered. >> During evaluation of In[21]:= \[Infinity]::indet: Indeterminate \ expression 0 ComplexInfinity encountered. >> Out[21]= Indeterminate Whether or to what extent we might improve the zero uncovering remains an open issue. There is a very real tradeoff in speed were Mathematica to try significantly harder to catch this sort of pathology. (....) (As regards RootReduce), it will "encapsulate" logarithms (which are decidely non-algebraic) in a way similar to Together, FactorSquareFree, et al. This could well mask that certain equivalent logs are algebraically related to one another, thus keeping zeros hidden. -------------------------------------------------------------------------- / Murray Eisenberg : > The issue of what a piece of software should do about 0/0 -- even when > it arises in precisely that form, without any CAS first simplifying > algebraic expressions to reach that form -- is a sticky one. The issue > was a mildly hot one many years ago in connection with the programming > language APL (from which parts of the Mathematica language are > descended). Aside from the possibility of signaling an error, there are > two other "good" possibilities for 0/0: 0 and 1. So I proposed in APL > that the handling be user-specifiable. > > The simple answer is that there is no good way to handle 0/0 that will > satisfy everyone. > > dimitris wrote: > > Hi fellas. > > This appeared in another forum as part of a question > > what another CAS does. > > Just of curiosity I check Mathematica's performance (5.2). > > The result was poor! > > > > Here is the expression > > > > > > In[16]:= > > o = (Log[2]*Cos[Pi/12] - Log[2]*Sin[Pi/12] - 2*Cos[Pi/12] + 2*Sin[Pi/ > > 12] + Sqrt[2] + > > 2*Log[Cos[Pi/12] - Sin[Pi/12]]*Cos[Pi/12] - 2*Log[Cos[Pi/12] - > > Sin[Pi/12]]*Sin[Pi/12])/ > > (Log[2]*Cos[Pi/12] - Log[2]*Sin[Pi/12] + 2*Log[Cos[Pi/12] - > > Sin[Pi/ > > 12]]*Cos[Pi/12] - > > 2*Log[Cos[Pi/12] - Sin[Pi/12]]*Sin[Pi/12]) > > > > > > Out[16]= > > (Sqrt[2] + (-1 + Sqrt[3])/Sqrt[2] - (1 + Sqrt[3])/Sqrt[2] - ((-1 + > > Sqrt[3])*Log[2])/(2*Sqrt[2]) + > > ((1 + Sqrt[3])*Log[2])/(2*Sqrt[2]) - ((-1 + Sqrt[3])*Log[-((-1 + > > Sqrt[3])/(2*Sqrt[2])) + (1 + Sqrt[3])/(2*Sqrt[2])])/ > > Sqrt[2] + ((1 + Sqrt[3])*Log[-((-1 + Sqrt[3])/(2*Sqrt[2])) + (1 + > > Sqrt[3])/(2*Sqrt[2])])/Sqrt[2])/ > > (-(((-1 + Sqrt[3])*Log[2])/(2*Sqrt[2])) + ((1 + Sqrt[3])*Log[2])/ > > (2*Sqrt[2]) - > > ((-1 + Sqrt[3])*Log[-((-1 + Sqrt[3])/(2*Sqrt[2])) + (1 + Sqrt[3])/ > > (2*Sqrt[2])])/Sqrt[2] + > > ((1 + Sqrt[3])*Log[-((-1 + Sqrt[3])/(2*Sqrt[2])) + (1 + Sqrt[3])/ > > (2*Sqrt[2])])/Sqrt[2]) > > > > Watch now a really bad performance! > > > > In[17]:= > > (Simplify[#1[o]] & ) /@ {Numerator, Denominator} > > > > Out[17]= > > {0, 0} > > > > That is Mathematica simplifies succesfully both the numerator > > and denominator to zero. So, you wonder what goes wrong? > > > > Try now to simplify the whole expression! > > > > In[19]:= > > Simplify[o] > > > > Out[19]= > > 1 > > > > A very weird result to my opinion! > > Simplification of 0/0 to 1? > > I think no simplification or some > > warning messages would be much better > > than 1! > > > > Note also that > > > > In[20]:= > > RootReduce[o] > > > > Out[20]= > > 1 > > > > Dimitris > > > > > > -- > Murray Eisenberg murray at math.umass.edu > Mathematics & Statistics Dept. > Lederle Graduate Research Tower phone 413 549-1020 (H) > University of Massachusetts 413 545-2859 (W) > 710 North Pleasant Street fax 413 545-1801 > Amherst, MA 01003-9305

**References**:**simplification of 0/0 to 1?***From:*dimitris <dimmechan@yahoo.com>