MathGroup Archive 2002

[Date Index] [Thread Index] [Author Index]

Search the Archive

Re: Bug in Simplify?

  • To: mathgroup at smc.vnet.net
  • Subject: [mg33193] Re: Bug in Simplify?
  • From: adam.smith at hillsdale.edu (Adam Smith)
  • Date: Thu, 7 Mar 2002 02:23:52 -0500 (EST)
  • References: <a61v7q$gpt$1@smc.vnet.net> <a64fu0$n04$1@smc.vnet.net>
  • Sender: owner-wri-mathgroup at wolfram.com

I agree with almost all of what you said.  Thanks for the reference.

It might indeed be impractical to ask what I have said.  But searching
through the help in Mathematica I found no warnings that using
Assumptions might fail in cases where an indeterminate form results. 
I don't think that it is too much to ask that the user be given an
explanation that Simplify with Assumptions can fail for some cases
(like the one I mentioned) and advising the user to check the results.
 Warnings like this appear, for example, in Solve when it has to use
inverse functions to get the solution.  In this case it would seem
fairly easy to have a warning something like "Simplify with Integers
and the form Sin[Integer Pi] does not check for the special case where
the numerator and denominator both equal zero.  It automatically
returns zero"  Obviously the code already identifies a trig function
that equals zero for integers, so I would think the basic requirements
are already there for this check.

The one thing that I would respectfully disagree with is the
comparison of 0/x and Sin[n Pi]/n.  If I were applying

Simplify[ Sin[n Pi]/x, Element[n,Integers]]

and it returns zero, I could understand the claim that it correctly
equals zero - Because I did not ask Simplify to put any conditions on
x.  Although I would ideally want it to leave the unevaluated form of
"0/x".  That way the result could be used in a later step where for
example I put conditions on x.  Having said that, I can understand
that choices have to be made in the code and can live with the
returned value of zero in this case.

But in the case of 

Simplify[ Sin[n Pi]/n, Element[n,Integers]]

I am applying a condition that effects both the numerator and
denominator.

Adam Smith    



"David W. Cantrell" <DWCantrell at sigmaxi.org> wrote in message news:<a64fu0$n04$1 at smc.vnet.net>...
> adam.smith at hillsdale.edu (Adam Smith) wrote:
> > I was recently working with some trig functions.  More specifically
> > for quantum mechanics where one often has terms like Sin[n Pi].  I
> > noticed what seemed a bug in Mathematica's Simplify[,Assumptions].
> >
> > In[1]:=
> > Simplify[Sin[n*Pi]/n, Element[n,Integers]]
> >
> > Out[1]=
> > 0
> 
> This is certainly not a bug. Note that 0/x simplifies to 0, period.
> Of course, you might well argue that, when simplifying 0/x to 0, some
> indication should be provided that that result is not valid if x = 0.
> Are there computer algebra systems which standardly
> provide such qualifications? Is it possible to specifically request
> Mathematica to provide such qualifications? I don't know the answers to
> these two questions. But stating fully the qualifications required for
> all simplifications in a messy computation could easily overwhelm the
> ordinary user. You might take a look at "Crimes and Misdemeanors in
> the Computer Algebra Trade", David R. Stoutemyer, _Notices of the
> American Mathematical Society_ 38:7 (1991) 778-785. Does anyone have
> references to similar discussions by other authors? If so, I'd be quite
> interested in reading them.
> 
> > Which is fine as long as n is not zero.
> >
> > In[2]:=
> > Limit[Sin[n*Pi]/n, n -> 0]
> >
> > Out[2]=
> > Pi
> >
> > It appears to me that Simplify is correctly determining that Sin[n
> > Pi]=0 for n an integer, but it ignores the fact that there is an
> > indeterminate 0/0.  I realize that this is a special case, but it
> > seems to occur often enough that it should be handled properly
> 
> I'm not entirely sure what you think "handled properly" would be.
> For me, in a system in which 0/0 is undefined,
> Simplify[Sin[n*Pi]/n, Element[n,Integers]] should yield
> 0 if n is nonzero, undefined if n is 0.
> 
> > or at least provide a warning message that one should double check
> > the results.
> >
> > Am I being picky or do others feel the same?
> 
> You're not being picky, at least IMO. But perhaps what you would like
> is not practical.
> 
> Regards,
>   David Cantrell


  • Prev by Date: Thanks to all for the help - and a roadie question....
  • Next by Date: limit crash
  • Previous by thread: Re: Bug in Simplify?
  • Next by thread: Re: Bug in Simplify?