Sounds good. I do wonder now if the existing radcans cause issues. Seems that it's ok. There aren't a lot (if any?) issues on rischint producing bad answers. But haven't checked the bug list in a while for this. The mailing list does have examples of radcan simplifying things to zero, but you wouldn't get that by hand because you wouldn't choose those branch cuts.
The commit says you used radcan. Are you sure that's right? radcan sometimes chooses an unexpected branch which is sometimes wrong. I have a vague memory that I removed calls to radcan in various places because that's what was happening to produce incorrect results.
Good question. I think I prefer your solution because acoth(x) is real only when abs(x) >= 1. For kicks, I tried integrate(acoth(x),x,1,t): (%i22) integrate(acoth(x),x,1,t); Is t - 1 positive, negative or zero? pos; Evaluation took 0.0400 seconds (1.8600 elapsed) using 2.560 MB. 2 1 log(t - 1) + 2 atanh(─) t + %i %pi t %i %pi (%o22) ─────────────────────────────────── - log(2) - ────── 2 2 (%i23) expand(%); Evaluation took 0.0000 seconds (0.0000 elapsed) using 12.617 KB. 2 log(t - 1) 1 (%o23) ───────────...
We should document the gcd variable. gcd: default throws an error that it's not valid, of course. But doesn't say what would be valid, and there's no way a user can know what would be valid. So two things: document the variable and fix up the error message to give a hint on what's valid.
Allowing gcd:default works for me. I never bothered to learn what all the different gcd algorithms do anyway. But isn't $gcd used all over? Allowing 'default would complicate things a bit, right?
This should probably be documented in the manual? Although you've already fixed this, maybe it should have just signaled an error if spmod can't handle it instead? Magically changing the gcd algorithm for this case mkes it difficult to know what happened if you have spmod but some other algorithm was actually used. Note: I didn't look at the changes you actually made.
Oops. The derivatives should use $x and $y. defgrad should probably do more error checking. Maybe make sure every variable in the derivatives start with a $?
Support reading compressed info files