expand((vt . a^^(-1) . u+1)^^(-2))
causes a stack overflow (sometimes crashing Maxima
entirely) ... infinite recursion in simpncexpt
Logged In: YES
Simpler case: (a + 1)^^(-1) . (a + 1)^^(-1), expon:2;
The problem is that simpnct and simpncexpt are passing the
buck to each other in cases like this. Simpncexpt correctly
expands (a+1)^^3 as (a+1).(a+1)^^2, letting simpnct take
care of the expansion, which it does. But it also tries to
expand (a+1)^^(-3) as (a+1)^^-1 . (a+1)^^-2, but simpnct
doesn't recognize that case.
Another, less dramatic, bug: expand(a^^-1 . (b+c)^^-1)
does not expand at all.
Note that there's no way to combine the parts within the
powers without expanding out the powers -- same problem
with commutative multiplication. That is, how do I simplify
a^n * (1+1/a)^n => (a * (1+1/a))^n => (a+1)^n , or to get
a little fancier, (1/a+1)^(n+k)*a^(n+m) => a^(m-k)*(a+1)^
(n+k). Radcan will do it, but at the cost of losing control
over the simplification. Perhaps some variant of multthru is
needed, or a new powerscontract.
Here is a fix. Note that this does NOT solve the general
problem of expanding .-expressions. For example, it does not
expand a . (a + 1)^^-1 to a^^-1 + 1. But I wanted to get
the fatal error fixed first. Also, it is not clear that Expand
gives you enough fine control to do that sort of thing
----- Fix in simpncexpt
;; This does the same thing as above for (A+B)^^(-2)
;; and (A.B)^^(-2).
((and (or (mplusp factor)
(and (not $dotexptsimp) (mnctimesp factor)))
(not (greaterp (minus power) $expon))
(< power -1))
(let (($expop $expon))
(ncpower (ncpower factor (- power)) -1)))
Logged In: YES
Suggested fixed applied (mdot.lisp CVS r 1.4_; also appended new regression
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.