Services & Resources / Wolfram Forums
-----
 /
MathGroup Archive
1996
*January
*February
*March
*April
*May
*June
*July
*August
*September
*October
*November
*December
*Archive Index
*Ask about this page
*Print this page
*Give us feedback
*Sign up for the Wolfram Insider

MathGroup Archive 1996

[Date Index] [Thread Index] [Author Index]

Search the Archive

Re: Complex Default

  • To: mathgroup at smc.vnet.net
  • Subject: [mg3057] Re: Complex Default
  • From: withoff (David Withoff)
  • Date: Tue, 30 Jan 1996 02:21:48 -0500
  • Organization: Wolfram Research, Inc.
  • Sender: owner-wri-mathgroup 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

==== [MESSAGE SEPARATOR] ====


  • Prev by Date: Re: Map Attractors in Mathematica
  • Next by Date: Re: Complex Default
  • Previous by thread: Re: Complex Default
  • Next by thread: Re: Complex Default