Re: Complex Default
- Subject: [mg3052] Re: Complex Default
- From: evans at gte.net (Mark Evans)
- Date: 28 Jan 1996 10:52:36 -0600
- Approved: usenet@wri.com
- Distribution: local
- Newsgroups: wri.mathgroup
- Organization: GTE Intelligent Network Services, GTE INS
- Sender: daemon 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