Complex Default

*To*: mathgroup at smc.vnet.net*Subject*: [mg3031] Complex Default*From*: evans at gte.net (Mark Evans)*Date*: Wed, 24 Jan 1996 03:34:30 -0500*Organization*: GTE Intelligent Network Services, GTE INS

The following was a suggestion I sent to Wolfram Research some time ago. I am curious what other people think of it. Mark Evans evans at gte.net Gentlemen: This suggestion relates to the use of complex numbers in Mathematica. Mathematica should incorporate a global user setting that shuts off the implicit assumption that undefined variables are complex numbers. When used, this preference setting would mean that instead of In[1]:= realVar Out[1]= realVar In[2]:= Re[realVar] Out[2]= Re[realVar] In[3]:= Im[realVar] Out[3]= Im[realVar] In[4]:= Arg[realVar] Out[4]= Arg[realVar] In[5]:= Abs[realVar] Out[5]= Abs[realVar] we would get some simplifications with $ComplexDefault = False: In[1]:= realVar Out[1]= realVar In[2]:= Re[realVar] (* known *) Out[2]= realVar In[3]:= Im[realVar] (* known *) Out[3]= 0 In[4]:= Arg[realVar] (* known *) Out[4]= 0 In[5]:= Abs[realVar] (* could be +/- realVar; leave unknown *) Out[5]= Abs[realVar] I think you would implement this as a system variable, say $ComplexDefault = [True | False]. The above outputs would correspond to $ComplexDefault = True and $ComplexDefault = False, respectively. It turns out that even when working with phasors, all of my undefined variables are real. Expressions only become complex when I personally insert the imaginary unit. These insertions are the only occurrence of the imaginary unit in all of the computations. Under such circumstances, I have been somewhat frustrated by Mathematica's refusal to simplify expressions on the chance that a complex number might be hiding behind symbols I know to be real. Try, for example, Conjugate[Exp[I x]]. Here was an interesting variant: In[44]:= Timing[Conjugate[Exp[I (kx^2 + ky^2)]]] Out[44]= 2 2 I (kx + ky ) {12.05 Second, Conjugate[E ]} Thus on an PowerMac 8100/80 MHz, it took Mathematica 12 seconds to find out that it did not know how to negate the minus sign in a very simple complex exponential. This was with Roman Maeder's "ReIm" package already loaded. When I defined kx and ky to be real per his package, the time was reduced to 3.5 seconds; still a long time for such a simple thing. This expression is like 2+2. It should be a snap. I suspect this is a problem in the start-up code that pattern-matches the form of the input. This is precisely my point, and it obtains more generally in Mathematica: we want to keep general-purpose symbolic code, but we would also like to see greater convenience in manipulation of expressions with known character. I have perused the ComplexExpand.m package and find that it is encumbered with far too much generality for my purposes. If you experiment with (symbolic) complex numbers, using ComplexExpand[], Conjugate[], Re[], and so on, you will find that even when it is possible to get a final answer, the wait is very long. I have also examined Roman Maeder's "ReIm" package. I like the idea of using upvalues to clarify whether a symbol is real or complex. However, it is a debatable matter how these upvalues should be treated when $ComplexDefault = False. I suppose the way to handle this situation is to stipulate symmetry. Thus $ComplexDefault = False means that an undefined symbol is REAL unless specifically upvalued into a COMPLEX number; and $ComplexDefault = True means the symbol is COMPLEX unless specifically upvalued into a REAL number. It would cost a little bit more time in terms of lookups, but tolerable amounts for completeness' sake. I think this whole concept is philosophically sound as well. The new system variable would be a user-definable statement of his working habits. If you have qualms, consider the following. Quaternions are a generalization of complex numbers, but you don't initialize the Mathematica kernel with the assumption that any undefined symbol can be a quaternion. You stop off at complex numbers, because they are far more common than quaternions. This being the case, why not allow the user to terminate generalizing assumptions at the field of real numbers? Real numbers are far more common than complex numbers, just as complex numbers are far more common than quaternions. The workaround I have developed for now is simply to replace occurences of Complex[a_,b_] with Complex[a,-b]: conj[number_] := number /. {Complex[re_,im_] -> Complex[re, -im]} The rules of complex algebra are such that this simple formula is generally safe. Thus (u1 + u2)* = u1* + u2*, (u1 u2)* = u1* u2*, (u1/u2)* = (u1*/u2*). In these cases the replacement rule works. General algebraic expressions can therefore be input to conj[] and will come out all right. (I would be interested if you think of any problematic cases.) When $ComplexDefault = False, the kernel would still return complex roots, eigenvalues, and the like when asked for them. What we are talking about here are the kernel's internal assumptions about undefined symbols. You might have the kernel issue messages each time the assumption could lead to erroneous output for the sake of unwary users. Personally, I would Off[] this message in my Init.m file. You might well have to implement additional C++ and Mathematica code modules to handle special cases when arguments to various functions can be assumed real. However the resulting speed improvements would probably pay for those efforts. Mark Evans evans at gte.net ==== [MESSAGE SEPARATOR] ====

**Matrix Algebra Weaknesses**

**Complex Default**

**Re: Matrix Algebra Weaknesses**

**Complex Default**