Raymond Toy

clisp doesn't have signed zeros and returns #c(1.57 -0.549). cmucl returns a different value for atanh(2): #C(0.54930615 -1.5707964). This is because long ago I carefully derived the value from first principals and using Kahan's convention of not spuriously adding a signed real part unless absolutely necessary. (Or maybe that was for acot? I forget now.) Anyway, dealing with branch cuts is quite complicated with or without signed-zeroes, and I've generally followed Kahan's conventions as shown in...

Using a bulid from Sep 22, I get: (%i3) atan(-2.0*%i); (%o3) 1.5707963267948966 - 0.5493061443340549 %i But clisp, cmucl, and sbcl say (atan #c(0 -2.0)) is #C(1.5707964 -0.54930615). It's going to be really confusing if we make Maxima return different values.

Neatly indent mbinding in defgrad gamma_incomplete

A note. The assume(b>0) is important. Without it, you just get the noun form for the derivative.

I think I'd prefer to keep existing behavior where only real results are returned. (Is that true for other elementary functions? I don't know.) But maybe ask on the mailing list for a consensus since we disagree?

I guess this is kind of an historical artifact where Maxima worked with real numbers instead of complex. Also note that acos(2) returns the noun form, but a call to rectform will give -(%i*log(2-sqrt(3))). Also rectform(acosh(0)) returns %i*%pi/2. What is my point? Not sure, but I think we should be consistent here so if we're going to simplify acosh(0), we should also simplify acos(2). However, I think I'd prefer to use rectform to get the complex value.

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.