(1) In my experience (mathematical physics, education, ...)
there are no agreed on values for the inverse trig functions
on their branch cuts. The definitions given in various
CL specifications are not standard in mathematics, physics, or
education. Further A&S do not define the inverse trig functions on
the branches.
(2) There are no compelling mathematical reasons for the
continuity requirements given in the various CL standards.
I'm sure that some choices are better than others, but
other than making the functions continuous on as large a
set as possible, there is no mathematical justification
for the rules.
(3) If Maxima's inverse trig functions followed
the CL standards, the functions logarc and rectform would
have to involve burdensome conditional statements; there
would even need a clause 'if lisp_supports_signed_zero then ....'
I don't think we want this.
(4) sbcl, clispm and cmucl users are going to be
disappointed when they discover that atanh evaluates
using (log(1 + x) - log(1 - x)) / 2; for example
(%i1) myatanh(x) := (x : float(x), (log(1.0+x) - log(1.0-x))/2.0)$
(%i2) :lisp(cl:atanh 1.5d-16);
2.2204460492503128E-16
(%i2) myatanh(1.5d-16);
(%o2) 1.6653345369377348*10^-16
Surely being chaotically wrong is worse than being
consistently wrong with a standard that has no
compelling mathematical justification. But as of
today, that is what Maxima does: see
http://cvs.sourceforge.net/viewcvs.py/maxima/maxima/src/trigi.lisp?r1=1.18&r2=1.18.2.1&sortby=date&only_with_tag=RELEASE-5_9_3-BRANCH
(5) How would I fix this? One possibility is to signal an error
for floating point evaluation on any branch. How often would a
user complain? Maybe once a decade (there would always be a
workaround.) There is some logic to this as well -- if floats
are fuzzy blobs (they are and they are not), a user might actually
appreciate getting an error.
Barton