Problem with Dyalog's arctanh function?

[Andrew Sengul]

In Dyalog:
¯7○¯2
0.5493061443J¯1.570796327

In GNU APL:
¯7○¯2
¯0.5493061443J1.570796327

In Common Lisp:
* (atanh -2)
#C(-0.54930615 1.5707964)

In Wolfram Alpha:
arctanh(-2)

Decimal approximation:

-0.54930614433405484569762261846126285232374527891137472586734716... +
1.5707963267948966192313216916397514420985846996875529104874722... i

Why is Dyalog's result negated and conjugated?

Andrew

[Sam Sirlin]

A Bug. Is the tanh of the result correct? In J

_7 o. _2
_0.549306j1.5708
a=. _7 o. _2
7 o. a
_2
7 o. -a
2

Also in octave:

octave:2> a = atanh(-2)
a = -5.4931e-01 + 1.5708e+00i
octave:3> tanh(a)
ans = -2.0000e+00 + 1.8370e-16i
octave:4> tanh(-a)
ans = 2.0000e+00 - 1.8370e-16i

Note there is ambiguity on the imaginary part:

octave:12> A = log( 1/sqrt(3))
A = -5.4931e-01
octave:16> tanh( A + i*pi/2)
ans = -2.0000e+00 + 1.8370e-16i
octave:17> tanh( A - i*pi/2)
ans = -2.0000e+00 - 1.8370e-16i

[eki...@gmail.com]

Circular and hyperbolic functions are all periodic, so for each such function f ,
there are infinitely many choice for f x for each x. The same is true (in the complex
plane) for the exponential function. It's not possible to define inverses for these
functions that are both single valued and continuous on the complex plane. It is
possible, though too specify where the discontinuities should be, and what values
should be taken at points of discontinuity, in a way that is consistent across all
the inverses.

IIRC the APL Extended standard follows Paul Penfield's APL 81 paper "Principal
values and branch cuts in complex APL" in specifying how these choice are to be
made, where the discontinuities should be and values at the points of discontinuity.
There is a long discussion (which cites and is largely based on the Penfield paper),
with illustrations, in Guy Steele's "Common Lisp, The Language (2nd Ed.)",
at section 12.5.3.

IMHO the J implementation is almost certainly correct, because ... Roger.

[eki...@gmail.com]

Or maybe not, since J and CL differ.

[Andrew Sengul]

J and CL are the same: negative real part, positive imaginary.

[eki...@gmail.com]

[eki...@gmail.com]

On Sunday, October 11, 2020 at 10:55:42 PM UTC-4, Andrew Sengul wrote:

My mistake. Back to my original conclusion: J and CL are (and GNU APL,
Octave, and W-ALPHA) , with probability VERY close to 1, consistent across
the ln / circular / hyperbolic fns, and so "correct" in a way that Dyalog is not.

Has anyone checked APL2?

[David Dooner]

From APL2
¯7○¯2
¯0.5493061443J1.570796327

[Sam Sirlin]

Here's a bit more thorough test, in J

] i=. i. 13
0 1 2 3 4 5 6 7 8 9 10 11 12
b=. (-i) o. _2
(,.i),"1 b,"0 i o.b
0 0j1.73205 2
1 _1.5708j1.31696 _2
2 3.14159j_1.31696 _2
3 _1.10715 _2
4 _1.73205 2
5 _1.44364 _2
6 1.31696j3.14159 _2
7 _0.549306j1.5708 _2
8 0j_2.23607 2
9 _2 _2
10 _2 2
11 0j_2 _2
12 _0.416147j_0.909297 _2

These are the standard inverse circular fns applied to (-2), and then the circular function applied to the result. Not all are strictly function/inverse pairs. I believe this to be the standard behavior.

(Hope the formatting looks ok. This interface is rather a pain)

[Roger Hui]

The Dyalog implementation follows Penfield 1981 (_Principal Values and Branch Cuts in Complex APL_, https://doi.org/10.1145/800142.805368), equation 12:

arctanh←{⍟(1+⍵)×(÷1-⍵*2)*0.5}

arctanh ¯2
¯0.5493061443J¯1.570796327

¯7 ○ ¯2
¯0.5493061443J¯1.570796327

On Friday, October 9, 2020 at 5:37:44 AM UTC-7, Andrew Sengul wrote:

[Bob Smith]

On 10/27/2020 3:58 PM, Roger Hui wrote:
> The Dyalog implementation follows Penfield 1981 (_Principal Values and Branch Cuts in Complex APL_, https://doi.org/10.1145/800142.805368), equation 12:
>
> arctanh←{⍟(1+⍵)×(÷1-⍵*2)*0.5}
>
> arctanh ¯2
> ¯0.5493061443J¯1.570796327
>
> ¯7 ○ ¯2
> ¯0.5493061443J¯1.570796327

There is some disagreement about Paul Penfield's choice in his 1981
paper of branch cut direction (CW vs. CCW) on arctan (and by extension,
arctanh) with which I agree. For a more detailed analysis, see Kahan[1]
(search for "APL") and Steele[2].

The latter reference recommends the definitions

atan ←{((⍟1+⍵×0J1)-⍟1-⍵×0J1)÷0J2}
atanh←{((⍟1+⍵ )-⍟1-⍵ )÷ 2}

More importantly, note that Steele[2] ends with the following sentence:

"Paul Penfield of MIT, after whose article the Common Lisp branch cuts
were originally patterned, endorses this change."

If you accept the argument to use the other branch cut direction on both
arctan and arctanh, then the above formulation of arctanh yields

atanh ¯2
¯0.5493061443J1.570796327

which produces the result (on the positive imaginary axis) chosen by
various implementations including NARS2000, APL2, GNU APL, J, Common
Lisp, GSL, MPC, Octave, and Wolfram Alpha. One small reason I prefer
the form in atanh is that it doesn't rely upon the default choice of the
positive result of square root that arctanh uses, but this is not a big
deal.

I don't know the rationale behind other implementations, but this is why
NARS2000 produces that result.

References

[1] Kahan, W. "Branch Cuts for Complex Elementary
Functions, or Much Ado About Nothing's Sign Bit"
in Iserles and Powell (eds.) "The State of the Art
in Numerical Analysis", pp. 165-211, Clarendon
Press, 1987, https://people.freebsd.org/~das/kahan86branch.pdf

[2] Steele, "Complex ATAN Branch Cut"
http://clhs.lisp.se/Issues/iss069_w.htm

--
_________________________________________
Bob Smith -- bsm...@sudleydeplacespam.com
http://www.sudleyplace.com - http://www.nars2000.org

To reply to me directly, delete "despam".

[Paul Penfield]

Bob is exactly right. I came up with my definitions for publication within the APL community in 1981. There was a need for a few choices of which side of a branch cut the functions would be continuous. In one or two cases (after all these years I can't remember which) there was already a commonly accepted convention. In others there was none. The arc tanh example under discussion resulted from one of those. When Guy Steele realized that my definitions and the ones made by Kahan had one of those choices different, he sought my advice. Kahan and I talked for several hours one day (I can't remember whether he called me or I called him). He explained that he had recommended one different choice about branch cut continuity to HP for incorporation in one of their calculators that handled complex numbers, as I recall about 1983. At first he felt he had logic on his side because of some identities that he liked or relied on were preserved by his choice but not mine. I understood that neither choice actually preserved all the identities, and convinced him of that. I think we ended up understanding that relying on preservation of identities simply transformed the discussion to be about which identities were more liked than others.

I had done a VERY thorough literature search and concluded that prior to my work nobody had articulated any preferences. So I made an arbitrary choice and, I hope, explained that arbitraryness in my papers. On the other hand Kahan had a well deserved world reputation in the related mathematics. When he made his choices and the subsequent recommendations to HP, he was apparently unaware of my work and relied on his extensive experience. But in the final analysis his choices were, I believe, just as arbitrary as mine.

We did not end up with agreement on how to continue. It seemed obvious to me that everyone would be better served by having one definition rather than two when neither was fundamentally superior. If precedence was considered important, then my 1981 publications might have been the preferred choice, but I was not and still am not sure he didn't have some published work in which his choice had been used before 1981. On the other hand implementation of complex number APL systems did not happen right away, whereas the HP calculators using Kahan's definitions were, by the time we talked, already designed and, as I recall, available for purchase. So in terms of getting to market first, his definition should be preferred.

I believe the LISP community felt similarly. Later, when Guy Steele and I spoke, I had to agree their choice for Common LISP was reasonable, and told him so.

The one thing that I did not do at the time and should have, was to publicly endorse Kahan's choice and recommend that APL implementations discontinue using mine. I do regret that and can only excuse it by saying that my interests had by that time changed away from APL to other things including VLSI. Of course that is not a valid excuse. Perhaps this note can now serve that function. It is only 35 years too late.

> _________________________________________
> Bob Smith

[J. Clarke]

On Thu, 12 Nov 2020 15:36:59 -0800 (PST), Paul Penfield
<paul.pen...@gmail.com> wrote:

>Bob is exactly right. I came up with my definitions for publication within the APL community in 1981. There was a need for a few choices of which side of a branch cut the functions would be continuous. In one or two cases (after all these years I can't remember which) there was already a commonly accepted convention. In others
there was none. The arc tanh example under discussion resulted from one of those. When Guy Steele realized that my definitions and the ones made by Kahan had one of those choices different, he sought my advice. Kahan and I talked for several hours one day (I can't remember whether he called me or I called him). He explained
that he had recommended one different choice about branch cut continuity to HP for incorporation in one of their calculators that handled complex numbers, as I recall about 1983. At first he felt he had logic on his side because of some identities that he liked or relied on were preserved by his choice but not mine. I understood
>that neither choice actually preserved all the identities, and convinced him of that. I think we ended up understanding that relying on preservation of identities simply transformed the discussion to be about which identities were more liked than others.
>
>I had done a VERY thorough literature search and concluded that prior to my work nobody had articulated any preferences. So I made an arbitrary choice and, I hope, explained that arbitraryness in my papers. On the other hand Kahan had a well deserved world reputation in the related mathematics. When he made his choices and the
subsequent recommendations to HP, he was apparently unaware of my work and relied on his extensive experience. But in the final analysis his choices were, I believe, just as arbitrary as mine.
>
>We did not end up with agreement on how to continue. It seemed obvious to me that everyone would be better served by having one definition rather than two when neither was fundamentally superior. If precedence was considered important, then my 1981 publications might have been the preferred choice, but I was not and still am not
sure he didn't have some published work in which his choice had been used before 1981. On the other hand implementation of complex number APL systems did not happen right away, whereas the HP calculators using Kahan's definitions were, by the time we talked, already designed and, as I recall, available for purchase. So in terms
of getting to market first, his definition should be preferred.
>
>I believe the LISP community felt similarly. Later, when Guy Steele and I spoke, I had to agree their choice for Common LISP was reasonable, and told him so.
>
>The one thing that I did not do at the time and should have, was to publicly endorse Kahan's choice and recommend that APL implementations discontinue using mine. I do regret that and can only excuse it by saying that my interests had by that time changed away from APL to other things including VLSI. Of course that is not a
valid excuse. Perhaps this note can now serve that function. It is only 35 years too late.

This is kind of the old story. When there's more than one way to do
something and no sound reason to prefer one over the other, let the
user or the developer decide. We do it with quad-IO, why not with the
branch directions on complex calculations?

>
>On Wednesday, November 11, 2020 at 10:55:03 AM UTC-5, Bob Smith wrote:
>> On 10/27/2020 3:58 PM, Roger Hui wrote:
>> > The Dyalog implementation follows Penfield 1981 (_Principal Values and Branch Cuts in Complex APL_, https://doi.org/10.1145/800142.805368), equation 12:
>> >

>> > arctanh?{?(1+?)×(÷1-?*2)*0.5}
>> >
>> > arctanh ¯2
>> > ¯0.5493061443J¯1.570796327
>> >
>> > ¯7 ? ¯2

>> > ¯0.5493061443J¯1.570796327
>> There is some disagreement about Paul Penfield's choice in his 1981
>> paper of branch cut direction (CW vs. CCW) on arctan (and by extension,
>> arctanh) with which I agree. For a more detailed analysis, see Kahan[1]
>> (search for "APL") and Steele[2].
>>
>> The latter reference recommends the definitions
>>

>> atan ?{((?1+?×0J1)-?1-?×0J1)÷0J2}
>> atanh?{((?1+? )-?1-? )÷ 2}

[Elijah Stone]

On Thu, 12 Nov 2020, J. Clarke wrote:
> This is kind of the old story. When there's more than one way to do
> something and no sound reason to prefer one over the other, let the user
> or the developer decide. We do it with quad-IO, why not with the branch
> directions on complex calculations?

FWIW I have always thought ⎕io was not a great idea. Most people I have
spoken to on the matter feel similarly.

Any publication on APL needs to specify whether it has ⎕io as 1 or 0. (Or
do the trick where you add/subtract ⎕io to/from indices, which is if
anything even worse.) It bifurcates the language and makes it harder to
reason about as a unity.

If you need a trig function with branch cut that goes the other way,
define one inline. It's a fairly niche use-case, and not a particularly
burdensome definition; and it alleviates the main language of overloads.

-E

[J. Clarke]

On Sun, 15 Nov 2020 23:31:12 -0800, Elijah Stone <elr...@elronnd.net>
wrote:

>On Thu, 12 Nov 2020, J. Clarke wrote:
>> This is kind of the old story. When there's more than one way to do
>> something and no sound reason to prefer one over the other, let the user
>> or the developer decide. We do it with quad-IO, why not with the branch
>> directions on complex calculations?
>

>FWIW I have always thought ?io was not a great idea. Most people I have

>spoken to on the matter feel similarly.
>

>Any publication on APL needs to specify whether it has ?io as 1 or 0. (Or
>do the trick where you add/subtract ?io to/from indices, which is if

>anything even worse.) It bifurcates the language and makes it harder to
>reason about as a unity.

You assume the default unless otherwise specified. I've never found
it burdensome. If I need index 0 I can use it. If I need index 1 I
can use it. Makes things a lot easier when I have to import data that
was generated by a C program, for openers.

>If you need a trig function with branch cut that goes the other way,
>define one inline. It's a fairly niche use-case, and not a particularly
>burdensome definition; and it alleviates the main language of overloads.
>
> -E

And then you encounter an implementation that did it the other way and
instead of flipping a switch you have to recode.

[Andrew Sengul]

Hi Dr. Penfield, I didn't expect my question to lead to this. Thanks for
clearing up this bit of history, and with your endorsement I'm using the
Kahan convention for arctanh in my APL implementation. It compiles APL
to Common Lisp hence the inclusion of CL in my initial examples -
interesting to note how the Lisp/APL connections have persisted across
generations.

Andrew