[Date Index]
[Thread Index]
[Author Index]
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
Prev by Date:
**Re: Replacement according to the pattern**
Next by Date:
**Re: Normally Distributed Random Matrix**
Previous by thread:
**Re: Re: simplification of 0/0 to 1?**
Next by thread:
**Re: simplification of 0/0 to 1?**
| |