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: <email@example.com> <firstname.lastname@example.org>
- 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:= > > Simplify[Sin[n*Pi]/n, Element[n,Integers]] > > > > Out= > > 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:= > > Limit[Sin[n*Pi]/n, n -> 0] > > > > Out= > > 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