On 8/8/08, Stavros Macrakis <macrakis at alum.mit.edu> wrote:
> 1) Maxima in general assumes that all variables are real-valued. This
> assumption is implicit in many simplifications etc. Using
> declare(z,complex) should override this default, but it is not checked
> for in many places.
Well, that's a bug. Also, declare(foo, complex) where foo
is a function doesn't seem to have the same effect as
declare(x, complex) where x is a variable; that's bug too.
It's OK by me to assume that variables and functions are
real by default, but Maxima isn't consistent about that.
featurep(x, real) => false in the absence of any declaration
about x.
> Also, Maxima in general assumes that functions
> are real-valued. In theory, domain:complex overrides that default,
> but in practice it does not. e.g. abs(sqrt(x)) -> sqrt(x).
Just a few functions respect domain. It's not clear to me that
domain should exist as a separate flag anyway; it seems
preferable to change behavior by declarations about variables
and functions instead.
> 2) There is a very big difference between abs() and cabs(), and they
> should not be unified. In effect, abs is a noun form and cabs is a
> verb form. Cabs (like rectform or integrate or limit) is a *routine*
> which returns the absolute value of the expression by using a variety
> of techniques, including asking the user questions. Abs is a
> *mathematical function* which *represents* an absolute value. When
> the user writes abs(log(a)), he/she typically wants to manipulate that
> expression, not be asked a question about the sign of a, or get a
> messy expression like (if a>0 then log(a) else log(-a)+%i*%pi).
This is all quite puzzling to me. Other noun/verb forms are
unified, so should be arg/carg. If a messy expression is correct
and a simpler one is incorrect, Maxima should return the
correct one (or give up, if the correct one is really too painful).
If abs or arg cannot be simplified without asking questions,
just leave it be.
> These are *design decisions*, not bugs, and have been debated and
> thought about quite a bit. They may well need to be reconsidered, but
> this is NOT a matter of "fixing bugs", but "changing the
> specification".
The items mentioned under (1) above are apparently broken
by accident, while those under (2) are broken by design;
there isn't much difference from a user's point of view.
Robert Dodier