Re: Complex Default

*To*: mathgroup at smc.vnet.net*Subject*: [mg3052] Re: Complex Default*From*: evans at gte.net (Mark Evans)*Date*: Sun, 28 Jan 1996 03:22:28 -0500*Organization*: GTE Intelligent Network Services, GTE INS*Sender*: owner-wri-mathgroup at wri.com

Daniel, thank you for responding. I appreciate your feedback. As to the substance of your reply, I would simply take whatever approach seems easiest to achieve clean, simple, real-number symbolics. > A useful area for pursuit is that of simplification under assumptions. Exactly! Functions like Simplify[] and Conjugate[] are my prime targets. > A classic example might be input as > Simplify[Sqrt[x^2], AssumptionList->{Re[x] > 4}] > I expect we will pursue this in the not-too-distant future, as it is both > useful and not completely unreasonable to implement (well, depends on the > expectations of the user, I guess). Yours is indeed a classic example. In the vast majority of engineering work, when one sees Sqrt[x^2], one immediately writes 'x' in its place. Only when one studies mathematics, theoretical physics, and semi-theoretical areas of engineering does one contemplate complex domains. > (well, depends on the expectations of the user, I guess). To clarify: I want a way to configure Mathematica so that all undefined symbols are taken as reals, without explicit user intervention for each symbol. The purpose of this configuration is to obtain simplifications wherever possible. Put another way, its purpose is to move Mathematica away from a mathematical orientation toward an engineering orientation. This capability might be achieved in any number of ways. I offered one that struck me as a reasonable possibility; however I leave it up to WRI how best to achieve this capability. > I'll discuss the issue of global assumptions a bit more generally. I see > no way to design, let alone recode, the Mathematica kernel to handle > arbitrary user assumptions. How, for example, should Solve[x^2-3*x+4==0, > x] work with an assumption set of the form {Modulus->11, x!=3}? Only a mathematician would care. I am not asking for 'arbitrary' assumptions, just real-valued assumptions, and I think the request is reasonable because real-valued assumptions constitute 85% of all engineering work. I grant you this request will lead to special-case code (as opposed to generalized schemes to handle all possible user examples along the lines you lay down), but sometimes special-case code is justified. In other words, I'm not being more specific than to say that the symbol is real. That fact by itself leads to numerous simplifications. > Many functions we provide can make sense on domains other than the one > we use, and in some cases we try to extend these functions. The most > common method is to localize such extension to the function level, rather > than, say, through global assumptions. We do this via Options. > PolynomialGCD, for example, will take the option Modulus->prime because it > is well defined and reasonably common to take gcds of polynomials in the > field of integers modulo some prime. One can do > SetOptions[PolynomialGCD, Modulus->...] > to make ALL PolynomialGCD calls work over said modulus, but imagine the > chaos of, say, SetGlobalAssumptionsForAllFunctions[Modulus->...]. > Functions that do not handle modular numbers, e.g. Log, will be completely > at a loss. We do not need a generalized scheme to handle arbitrary mathematical domains for every function; that is why I used the example of quaternions in my post. These are nowhere to be seen in the product as sold. You could properly fault me for asking WRI to implement defaults relating to hyper-complex quaternion algebra. But it is not unreasonable to ask WRI to implement real-valued symbolics. Real-valued symbols are also "reasonably common"! Options are fine, and if you can achieve real-valued symbolics with Options, go for it. If all relevant functions had an option SymbolType->[Real | Complex], then WRI could setup the default option configuration for each affected function as SymbolType :> $SymbolType and allow the user to put $SymbolType = Real or $SymbolType = Complex, as desired, in his Init.m file. > What about handling assumptions on parameters, e.g. Solve[x^2 + > a*x + b == 0, x] with a, b, and x assumed real? The solns in general are > algebraic functions in the parameters a and b, and even for different real > values of a, b these functions will not in general be real-valued; to > fully specify where they are real valued would involve cylindrical > algebraic decomposition (CAD), itself a HARD problem to tackle. The output I get from Solve[x^2 + a*x + b == 0] is a pair of rules corresponding to the + and - forks of the quadratic formula. This output is entirely satisfactory. The fact that some real-valued parameter combinations will lead to complex, physically implausible results is where engineering judgment is called for. I am not asking Mathematica to take the place of the engineer, just let him ignore complex cases THAT ARISE ONLY WHEN SYMBOLS ARE COMPLEX. When you use the term "solutions," you are talking about math-theoretical solutions. In most engineering, one only speaks of a solution if it is a real-valued solution. Equations having only "complex solutions" in the mathematical sense have "no solution" in the engineering sense. If you pick up an engineering textbook, one on aeronautics for example, you'll see what I mean. The typical author presents an equation, then analyzes its behavior in all relevant physical domains as certain parameters vary. Some domains are "inaccessible" and these correspond to complex "solutions." I see no conflict in having real-valued symbols give rise to complex output (eignevalues, roots, etc.). In fact, the impetus for my suggestion came from my work with complex numbers in Mathematica. I found that the work would have proceeded more smoothly if Mathematica had treated just the "I" symbol as imaginary, not ALL my input symbols. So then, I am not asking Mathematica to identify solution boundaries for me (unless they are fairly easy to find). I am asking Mathematica to simplify expressions wherever possible by using the knowledge that symbols are real. It seems to me that more information can only help. Dave Wagner writes: > Better yet, I would suggest the introduction of a new attribute, > say "Real". Then you could simply SetAttributes[sym, Real] to tell > Mathematica that a variable is real. You can thus have your cake and > eat it too, because some symbols can be real while others would be > assumed to be complex. > > There's also a precedent for this: the attribute Constant. Constant > indicates that all derivatives for a symbol are 0. It is used by Dt. > The analogy with what I'm proposing is obvious. Dave's analogy, I take it, is that Im[sym] == 0. His proposal is also good. However, I am inclined to think that a more global approach is called for than either Attributes or Upvalues would provide. I mentioned Upvalues only as a way to override the default assumption. What I fundamentally want is a way to alter the default assumption. It would quickly get tedious tacking Attributes or Upvalues to each new symbol. One usually likes to create new symbols on the fly. The attribute/upvalue procedure should only be used for default overrides. Thanks, Daniel! Mark ==== [MESSAGE SEPARATOR] ====