[Date Index]
[Thread Index]
[Author Index]
Re: Re: Re: simplification of 0/0 to
As I indicated, the issue of what to do about 0/0 has been discussed and
argued at length elsewhere long ago. One thing that emerged from that
discussion is that there are situations where it is desirable for 0/0 to
return result 1, situations where it is desirable to return 0, and
situations where it is desirable to signal an error (lest something
dangerous occur). The new thing now is that with "algebraic"
simplifications made by a CAS, allowing either 1 0r 0 as result can
indeed be especially dangerous; I have no argument with that!
Andrzej Kozlowski wrote:
> I think if Mathematica followed your suggestion things might become
> just too good to be true! Note that:
>
> Simplify[(2*Cos[x]^2 + 2*Sin[x]^2 - 2)/(Cos[x]^2 + Sin[x]^2 - 1)]
> 2
>
> while
>
> Simplify[2*Cos[x]^2 + 2*Sin[x]^2 - 2]/Simplify[Cos[x]^2 + Sin[x]^2 - 1]
>
> would return 1 or 0 (or whatever the user specified, according to
> your suggestion).
>
> At least the fact that you get Indeterminate with an error message
> alerts you to what is going on, without that it would be easy to
> "prove" that 1==2 or whatever you wished (and hide it so deeply in an
> obscure "one-liner" nobody might notice). And since
>
> Implies[1 == 2, "The moon is made of green cheese"]
> True
>
> you could then prove anything you have ever wished to prove :-)
>
> Andrzej Kozlowski
>
>
>
>
> On 12 Jun 2007, at 14:27, Murray Eisenberg wrote:
>
>> 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
>>
>
>
--
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:
**Tabbed notebooks?**
Next by Date:
**Re: Arranging input data (nonlinear control systems)**
Previous by thread:
**Re: Re: simplification of 0/0 to 1?**
Next by thread:
**Re: Re: simplification of 0/0 to 1?**
| |