Re: branch cut fixup for atanh(bfloat(x))
Robert Dodier <robert.dodier <at> gmail.com>
2006-03-02 03:15:52 GMT
> For floating point evaluation, I propose that we define the inverse trig
> functions by their logarc forms (using log(-1) = i %pi). As far as I know, this is
> what Maxima has always done. Presumably, all simplifications in Maxima are
> consistent with this choice.
To the best of my knowledge, the prescribed CL branch cuts
coincide with Maxima's symbolic branch cuts.
So, whether by design or coincidence, we don't have to make
further choices here. But documenting Maxima's convention
is a really good idea.
> (1) For double floating point evaluation, we write functions
> maxima-branch-atanh, and etc . For an input that is on a branch cut,
> these functions would return a value that is consistent with the logarc
> form of the function. They should, however, use a numerically
> friendly version of the logarc form. For inputs off the branches, just
> use the cl functions. All lisps would use this scheme.
OK, I'll rename ATANH-HACK, etc to MAXIMA-BRANCH-ATANH, etc,
and cut the per-implementation conditional stuff #+(or sbcl clisp ...)
and then that's taken care of. (I revised ATANH-HACK, etc to punt
to CL:ATANH, etc whenever the input is not on a branch cut.)
> (2) I'm not so familiar with big floats, but I think basically the same
> scheme should be used: maxima-branch-big-atanh and etc.
No, I don't think that's necessary. There was only one problem
in the bigfloat stuff --- the derivation of a bigfloat formula for
atanh applied an identity which fails when Im z = 0. I put in
a special case for that and now it should be OK for all Lisp
versions. There's nobody to punt to (we own the sole bigfloat
trig implementation) so I don't see a need to split off the code
for branch cuts, since it already does the right
thing (i.e., it agrees with the symbolic code).
Hope this helps,