Barton,
> (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.
We just need to make a choice and stick with it.
CLHS has some importance here for 2 reasons.
One is that it hypothetically makes it possible to predict what
an implementation is going to return for inputs on the branch cut.
(Practically speaking, that's not the case. Oh well.)
The other is that CLHS attempts to follow some recommendations
of W Kahan. We can try to find our own way here, but chances are
good we'll end up following Kahan anyway, and if not him,
someone a lot like him.
> (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.
Yes, no compelling reason for anything here,
we just need to make a choice and stick with it.
> (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.
I don't understand which burdensome conditional statements you mean here.
As to signed zero, it's a PITA no matter which convention we adopt
for branch cuts, since CLHS allows implementations to give different
results depending on the presence or absence of it.
I suppose that's an argument for having no convention.
I don't think I want to go there.
> (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;
We can easily fix this by punting to cl:atanh for any input
not on a branch cut.
> (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.
Error messages mean that the user can't walk away from the console.
As to the frequency of users complaining about any of this stuff --
presumably we sweating the details so the users don't have to.
Why can't we choose something and stick with it?
All the best,
Robert