Re: Re: Some bugs in Mathematica
- To: mathgroup at smc.vnet.net
- Subject: [mg59771] Re: [mg59713] Re: Some bugs in Mathematica
- From: Daniel Lichtblau <danl at wolfram.com>
- Date: Sat, 20 Aug 2005 03:14:25 -0400 (EDT)
- References: <200508180417.AAA08605@smc.vnet.net>
- Sender: owner-wri-mathgroup at wolfram.com
Bill Rowe wrote: > On 8/17/05 at 4:00 AM, akhmel at hotmail.com (Alex) wrote: > > >>Bill Rowe wrote: >>It's more than reasonable. There are not that many substitutions. I >>can name 3 or 4. Can you name 125? > > > The actual number of substitutions is only one of several factors > than will affect execution time. My comment dealt with an expression > of arbitrary complexity. It is quite easy to replace one or more > variables in you integrand with a sum of say four or five terms, > expand the result to get something that is not easily reconizable > as equivalent. Your original comment implied you expect Mathematica > to try every possible grouping of variables in such an expression > to find the simple transformation. This is not a reasonable > expectation for expressions of arbitrary complexity. True. Moreover, one need not necessarily go out of one's way to make an example perversely difficult. See comments at bottom. >>>And your basis for this assertion is ....? > > >>I addressed it before, the substitutions are simple and the number >>of different substitutions is very limited. I tried several >>substitutions myself and got result of simplification practically >>immediately. And my computer is 5 years old, so it is not fast at >>all. Can you imagine how a fast computer would behave? This has little bearing on what a computational program will do, unless that program manages to find the identical substitution. More below. > Again, my comment was for an expression of arbitrary complexity. > Your comments here do not address the point. > > >>>How is "appearance" of an integrad to be defined for a system like >>>Mathematica? I am confident algorithm needed to define "appearance" >>>will lead to unacceptable performance if every possible grouping of >>>variables in an arbritrary complex expression is considered. > > >>You cannot have it both ways: you claim that Mathematica has a >>table of integrals, it means that they have managed to write a >>table in computer-readable and computer-searchable form. And now >>you are telling me that this just cannot be done! Now, which one is >>right? > > > You are conflating to separate things. One is the existence of > an integral table, The other is the ability to transform an > expression into a form that matches one of the forms tabulated. > Simply because a table exists doesn't mean you can transform a > complex expression into a form for which the table can be used. This barely scratches the surface. For indefinite integration one has tables to assist after e.g. an attempt using Risch fails. In working with tables on typically uses transformations to put an integrand into a "good" form. A particular example might be aided by use of Apart. Or Together. Or Factor. Or Expand. Or Collect on some pieces... Then the question arises as to how to prevent these from undoing one another, and to prevent infinite recursion as subpieces get transformed back into something resembling the original problem (l'Hospital's rule for limits can also misbehave in this way, by the by). There are other issues. Some transformations can, if done carelessly, result in antiderivatives that encorporate branch cut errors (I think this is mostly an issue with elliptics, where inverse functions tend to be used in the transformation process; but it can show up elsewhere). Some transformations can lead to antiderivatives that might be horribly more complicated than those attained by other methods. In some cases we may miss special cases due to alterations wrought by a transformation. This in fact was largely the issue with the integration in this thread, Integrate[1/(x*Sqrt[-a^2+x^2]*Sqrt[-b^2+x^2]), x] Note for example that an elementary function results from an essentially similar example: Integrate[1/(x*Sqrt[a^2-x^2]*Sqrt[b^2-x^2]), x] There are other land mines. Integration tables tend to be large. It is easy to misplace a special case after the general case (one can argue that this is sloppy programming; my experience is that most people familiar with integration of special functions do not have strong programming backgrounds so it may be understandable). And easier still, in rearranging code, to move a general case to a premature point that occludes relevant special cases. Even with several thousand tests in a suite, spotting the damage is not simple. A related matter is that it can be hard to get the most general form of a pattern applicable to an integration. Getting transformation code to know whether or how to pull factors apart inside powers, for example, is not a simple matter. This list of issues involved in transformations goes on. And this is only indefinite integration; the problems encountered in definite are vastly more troublesome. For those who keep score of such things, the betting hereabouts is around 40% that the original poster is a former WRI employee. Daniel Lichtblau Wolfram Research
- References:
- Re: Some bugs in Mathematica
- From: Bill Rowe <readnewsciv@earthlink.net>
- Re: Some bugs in Mathematica