Barton Willis

Most likely no. The iteration limit check is fast, but the cycle detection is slow. If we got rid of one check, maybe it should be the cycle detection?

A better version: (defmvar *max-fullratsimp-iterations* 32 "Maximum number of iterations allowed for fullratsimp before falling back.") (defmfun ($fullratsimp :properties ((evfun t))) (exp &rest argl) "Repeatedly applies `ratsimp` to `exp` until either (a) a fixpoint is reached, (b) a cycle is detected, or (c) the number of iterations exceeds *max-fullratsimp-iterations*." (labels ((local-ratsimp (e) (simplify (apply #'$ratsimp e argl)))) (let* ((k *max-fullratsimp-iterations*) (seen (list exp))...

Nice that you fixed the actual bug here. Nevertheless, I think that the function fullratsimp should have protection against infinite loops. Something like: (defmvar *max-fullratsimp-iterations* 32 "Maximum number of iterations allowed for fullratsimp before falling back.") (defmfun ($fullratsimp :properties ((evfun t))) (exp &rest argl) "Repeatedly applies `ratsimp` to an exp until either (a) a fixpoint is reached (b) cycle is detected (A -> B -> C -> A -> ...), or (c) the number of iterations exceeds...

error in matrix exponentiation

Fixed by Commit [48a0fb]. I attempted to fix all the bugs in this ticket; if not, let's open a new ticket for each separate bug. Till then, I'm closing this ticket.

Fixes for #2596 error in matrix exponentiation

li[0](complex float)

Setting domain to complex at the top of matrixexp and matfun fixes this bug. Here is a test: block([fpprec : 28, m, xxx,yyy, ratprint : false], seriesexp(a, k) := block([s : ident(3), t : ident(3)], for j : 1 thru k do (t : (t . a)/j, s : s + t), s), m : %i*matrix([1,2,3],[3,2,0],[1,2,1]), yyy : bfloat(rectform(matrixexp(m))), xxx : bfloat(seriesexp(m, 80)), is(mat_norm(xxx-yyy,'inf) < 1/10^25)); true$ The last two tests in rtest_matrixexp finish okay, but they are slow. Changing them to (mat : matrix([x,1,0],[1,1,1],[0,1,1]),...