Re: Complex Default

*Subject*: [mg3057] Re: Complex Default*From*: withoff (David Withoff)*Date*: 30 Jan 1996 05:17:46 -0600*Approved*: usenet@wri.com*Distribution*: local*Newsgroups*: wri.mathgroup*Organization*: Wolfram Research, Inc.*Sender*: daemon at wri.com

The recent exchange about assuming that symbols are real (or specifying other mathematical properties of expressions) has turned out to be more interesting than I had thought, given that this is such a common suggestion and such a well-travelled corner of computer algebra. All of the comments that have been made so far are essentially correct, and some of them have even been new (at least to me). It is important to make a distinction between the visible interface to this functionality and the underlying implementation. All of the suggested interfaces (attributes, options, global variables, etc.) seem fine, and will probably all play a role if and when the functionality that you want is implemented. If there isn't an algorithm that can do anything useful with the extra assumptions, though, then it doesn't much matter how you specify them. This is a common problem. The modifications needed to do something useful with the extra information are rarely simple. Sometimes, completely new algorithms are needed. Sometimes algorithms aren't available, or are prohibitively slow. Even when algorithms are available, implementing them can be a formidable task. Suppose, for example, that one function calls another, and that the first function is told that all of the symbols are real. The first function might introduce intermediate variables that are allowed to be complex (even in the most down-to-earth calculations, it is common to make temporary excursions into the complex plane), which it then passes along to the second function. The second function could be something like Solve, which may then be faced with the task of solving a system of complicated equations amidst a forest of assumptions about various symbols. It might need to know whether some combination of those symbols is real, or positive, or has some other property. Sometimes, it won't have enough information. What should it do then? Give up? Suppose that the algorithm for determining the properties of a particular combination of symbols is very time consuming. How hard should the program work to come up with a solution? It may be that a very tiny subset of this functionality will do many of the things that people want to do. It is easy to see that the general problem is close to impossible to solve, but maybe we don't need to solve the general problem. A first attempt at solving part of the problem can be found in the RealOnly.m package, which is available on MathSource. That package is a good example to illustrate what can and cannot be done without a terrific amount of work. It would be useful to have some examples of specific things that you wish Mathematica could do, and where it is actually possible to do them, including not just the interface, but also the underying algorithm, and where the extra functionality is worth the inevitable speed degradation. Finally, it might be useful to keep in mind that there are two types of solutions to this problem, which might be called the "hackery" approach and the "purist" approach. With the "hackery" approach, you add clever rules to Power, Solve, Integrate, and so forth, until the system processes most of the assumptions that you give it. That is a lot of work, and such systems always have embarassing cracks. Systems that use that approach seem to be acceptable for lots of people, though, as long as you don't push them too hard. The "purist" approach is to have the algorithms abandon the problem unless they can verify the required assumptions. For example, if the only available integration algorithm assumes that all of the symbols are generic complex numbers, then an input like Integrate[expr, x, RealSymbols -> True] would generate a warning message about the lack of an algorthm and give up. Dave Withoff Research and Development Wolfram Research