1. Forum
  2. Usenet
  3. COMP.LANG.APL

  • Problem with Dyalog's arctanh function?

    From Andrew Sengul@21:1/5 to All on Fri Oct 9 05:37:42 2020
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Sam Sirlin@21:1/5 to Andrew Sengul on Sat Oct 10 15:24:31 2020
    On Friday, October 9, 2020 at 5:37:44 AM UTC-7, Andrew Sengul wrote:
    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

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From ekimlpa@gmail.com@21:1/5 to eki...@gmail.com on Sun Oct 11 09:45:54 2020
    On Sunday, October 11, 2020 at 12:29:47 PM UTC-4, eki...@gmail.com wrote:
    On Saturday, October 10, 2020 at 6:24:33 PM UTC-4, Sam Sirlin wrote:
    On Friday, October 9, 2020 at 5:37:44 AM UTC-7, Andrew Sengul wrote:
    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
    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
    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.

    Or maybe not, since J and CL differ.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From ekimlpa@gmail.com@21:1/5 to Sam Sirlin on Sun Oct 11 09:29:46 2020
    On Saturday, October 10, 2020 at 6:24:33 PM UTC-4, Sam Sirlin wrote:
    On Friday, October 9, 2020 at 5:37:44 AM UTC-7, Andrew Sengul wrote:
    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
    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

    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andrew Sengul@21:1/5 to eki...@gmail.com on Sun Oct 11 19:55:39 2020
    On 10/11/20 9:45 AM, eki...@gmail.com wrote:
    On Sunday, October 11, 2020 at 12:29:47 PM UTC-4, eki...@gmail.com wrote:
    On Saturday, October 10, 2020 at 6:24:33 PM UTC-4, Sam Sirlin wrote:
    On Friday, October 9, 2020 at 5:37:44 AM UTC-7, Andrew Sengul wrote:
    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
    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
    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.

    Or maybe not, since J and CL differ.

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From ekimlpa@gmail.com@21:1/5 to Andrew Sengul on Mon Oct 12 12:15:06 2020
    On Sunday, October 11, 2020 at 10:55:42 PM UTC-4, Andrew Sengul wrote:
    On 10/11/20 9:45 AM, eki...@gmail.com wrote:
    On Sunday, October 11, 2020 at 12:29:47 PM UTC-4, eki...@gmail.com wrote:
    On Saturday, October 10, 2020 at 6:24:33 PM UTC-4, Sam Sirlin wrote:
    On Friday, October 9, 2020 at 5:37:44 AM UTC-7, Andrew Sengul wrote: >>>> 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
    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
    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.

    Or maybe not, since J and CL differ.

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From ekimlpa@gmail.com@21:1/5 to Andrew Sengul on Mon Oct 12 12:27:00 2020
    On Sunday, October 11, 2020 at 10:55:42 PM UTC-4, Andrew Sengul wrote:
    On 10/11/20 9:45 AM, eki...@gmail.com wrote:
    On Sunday, October 11, 2020 at 12:29:47 PM UTC-4, eki...@gmail.com wrote:
    On Saturday, October 10, 2020 at 6:24:33 PM UTC-4, Sam Sirlin wrote:
    On Friday, October 9, 2020 at 5:37:44 AM UTC-7, Andrew Sengul wrote: >>>> 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
    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
    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.

    Or maybe not, since J and CL differ.

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

    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?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From David Dooner@21:1/5 to eki...@gmail.com on Mon Oct 12 15:46:11 2020
    On Monday, October 12, 2020 at 3:27:01 PM UTC-4, eki...@gmail.com wrote:
    On Sunday, October 11, 2020 at 10:55:42 PM UTC-4, Andrew Sengul wrote:
    On 10/11/20 9:45 AM, eki...@gmail.com wrote:
    On Sunday, October 11, 2020 at 12:29:47 PM UTC-4, eki...@gmail.com wrote:
    On Saturday, October 10, 2020 at 6:24:33 PM UTC-4, Sam Sirlin wrote: >>> On Friday, October 9, 2020 at 5:37:44 AM UTC-7, Andrew Sengul wrote: >>>> 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
    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
    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.

    Or maybe not, since J and CL differ.

    J and CL are the same: negative real part, positive imaginary.
    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?

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Sam Sirlin@21:1/5 to All on Mon Oct 12 23:56:14 2020
    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)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Roger Hui@21:1/5 to Andrew Sengul on Tue Oct 27 12:58:15 2020
    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:
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bob Smith@21:1/5 to Roger Hui on Wed Nov 11 10:54:17 2020
    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 -- bsmith@sudleydeplacespam.com
    http://www.sudleyplace.com - http://www.nars2000.org

    To reply to me directly, delete "despam".

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul Penfield@21:1/5 to Bob Smith on Thu Nov 12 15:36:59 2020
    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.


    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}

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From J. Clarke@21:1/5 to paul.penfield.jr@gmail.com on Thu Nov 12 23:18:47 2020
    On Thu, 12 Nov 2020 15:36:59 -0800 (PST), Paul Penfield <paul.penfield.jr@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}

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From J. Clarke@21:1/5 to All on Mon Nov 16 02:49:03 2020
    On Sun, 15 Nov 2020 23:31:12 -0800, Elijah Stone <elronnd@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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Elijah Stone@21:1/5 to J. Clarke on Sun Nov 15 23:31:12 2020
    This message is in MIME format. The first part should be readable text,
    while the remaining parts are likely unreadable without MIME-aware tools.

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andrew Sengul@21:1/5 to All on Wed Dec 16 17:00:16 2020
    SGkgRHIuIFBlbmZpZWxkLCBJIGRpZG4ndCBleHBlY3QgbXkgcXVlc3Rpb24gdG8gbGVhZCB0 byB0aGlzLiBUaGFua3MgZm9yDQpjbGVhcmluZyB1cCB0aGlzIGJpdCBvZiBoaXN0b3J5LCBh bmQgd2l0aCB5b3VyIGVuZG9yc2VtZW50IEknbSB1c2luZyB0aGUNCkthaGFuIGNvbnZlbnRp b24gZm9yIGFyY3RhbmggaW4gbXkgQVBMIGltcGxlbWVudGF0aW9uLiBJdCBjb21waWxlcyBB UEwNCnRvIENvbW1vbiBMaXNwIGhlbmNlIHRoZSBpbmNsdXNpb24gb2YgQ0wgaW4gbXkgaW5p dGlhbCBleGFtcGxlcyAtDQppbnRlcmVzdGluZyB0byBub3RlIGhvdyB0aGUgTGlzcC9BUEwg Y29ubmVjdGlvbnMgaGF2ZSBwZXJzaXN0ZWQgYWNyb3NzDQpnZW5lcmF0aW9ucy4NCg0KQW5k cmV3DQoNCk9uIDExLzEyLzIwIDM6MzYgUE0sIFBhdWwgUGVuZmllbGQgd3JvdGU6DQo+IEJv YiBpcyBleGFjdGx5IHJpZ2h0LiAgSSBjYW1lIHVwIHdpdGggbXkgZGVmaW5pdGlvbnMgZm9y IHB1YmxpY2F0aW9uIHdpdGhpbiB0aGUgQVBMIGNvbW11bml0eSBpbiAxOTgxLiAgVGhlcmUg d2FzIGEgbmVlZCBmb3IgYSBmZXcgY2hvaWNlcyBvZiB3aGljaCBzaWRlIG9mIGEgYnJhbmNo IGN1dCB0aGUgZnVuY3Rpb25zIHdvdWxkIGJlIGNvbnRpbnVvdXMuICBJbiBvbmUgb3IgdHdv IGNhc2VzIChhZnRlciBhbGwgdGhlc2UgeWVhcnMgSSBjYW4ndCByZW1lbWJlciB3aGljaCkg dGhlcmUgd2FzIGFscmVhZHkgYSBjb21tb25seSBhY2NlcHRlZCBjb252ZW50aW9uLiAgSW4g b3RoZXJzIHRoZXJlIHdhcyBub25lLiAgVGhlIGFyYyB0YW5oIGV4YW1wbGUgdW5kZXIgZGlz Y3Vzc2lvbiByZXN1bHRlZCBmcm9tIG9uZSBvZiB0aG9zZS4gIFdoZW4gR3V5IFN0ZWVsZSBy ZWFsaXplZCB0aGF0IG15IGRlZmluaXRpb25zIGFuZCB0aGUgb25lcyBtYWRlIGJ5IEthaGFu IGhhZCBvbmUgb2YgdGhvc2UgY2hvaWNlcyBkaWZmZXJlbnQsIGhlIHNvdWdodCBteSBhZHZp Y2UuICBLYWhhbiBhbmQgSSB0YWxrZWQgZm9yIHNldmVyYWwgaG91cnMgb25lIGRheSAoSSBj YW4ndCByZW1lbWJlciB3aGV0aGVyIGhlIGNhbGxlZCBtZSBvciBJIGNhbGxlZCBoaW0pLiAg SGUgZXhwbGFpbmVkIHRoYXQgaGUgaGFkIHJlY29tbWVuZGVkIG9uZSBkaWZmZXJlbnQgY2hv aWNlIGFib3V0IGJyYW5jaCBjdXQgY29udGludWl0eSB0byBIUCBmb3IgaW5jb3Jwb3JhdGlv biBpbiBvbmUgb2YgdGhlaXIgY2FsY3VsYXRvcnMgdGhhdCBoYW5kbGVkIGNvbXBsZXggbnVt YmVycywgYXMgSSByZWNhbGwgYWJvdXQgMTk4My4gIEF0IGZpcnN0IGhlIGZlbHQgaGUgaGFk IGxvZ2ljIG9uIGhpcyBzaWRlIGJlY2F1c2Ugb2Ygc29tZSBpZGVudGl0aWVzIHRoYXQgaGUg bGlrZWQgb3IgcmVsaWVkIG9uIHdlcmUgcHJlc2VydmVkIGJ5IGhpcyBjaG9pY2UgYnV0IG5v dCBtaW5lLiAgSSB1bmRlcnN0b29kIHRoYXQgbmVpdGhlciBjaG9pY2UgYWN0dWFsbHkgcHJl c2VydmVkIGFsbCB0aGUgaWRlbnRpdGllcywgYW5kIGNvbnZpbmNlZCBoaW0gb2YgdGhhdC4g IEkgdGhpbmsgd2UgZW5kZWQgdXAgdW5kZXJzdGFuZGluZyB0aGF0IHJlbHlpbmcgb24gcHJl c2VydmF0aW9uIG9mIGlkZW50aXRpZXMgc2ltcGx5IHRyYW5zZm9ybWVkIHRoZSBkaXNjdXNz aW9uIHRvIGJlIGFib3V0IHdoaWNoIGlkZW50aXRpZXMgd2VyZSBtb3JlIGxpa2VkIHRoYW4g b3RoZXJzLg0KPiANCj4gSSBoYWQgZG9uZSBhIFZFUlkgdGhvcm91Z2ggbGl0ZXJhdHVyZSBz ZWFyY2ggYW5kIGNvbmNsdWRlZCB0aGF0IHByaW9yIHRvIG15IHdvcmsgbm9ib2R5IGhhZCBh cnRpY3VsYXRlZCBhbnkgcHJlZmVyZW5jZXMuICBTbyBJIG1hZGUgYW4gYXJiaXRyYXJ5IGNo b2ljZSBhbmQsIEkgaG9wZSwgZXhwbGFpbmVkIHRoYXQgYXJiaXRyYXJ5bmVzcyBpbiBteSBw YXBlcnMuICBPbiB0aGUgb3RoZXIgaGFuZCBLYWhhbiBoYWQgYSB3ZWxsIGRlc2VydmVkIHdv cmxkIHJlcHV0YXRpb24gaW4gdGhlIHJlbGF0ZWQgbWF0aGVtYXRpY3MuICBXaGVuIGhlIG1h ZGUgaGlzIGNob2ljZXMgYW5kIHRoZSBzdWJzZXF1ZW50IHJlY29tbWVuZGF0aW9ucyB0byBI UCwgaGUgd2FzIGFwcGFyZW50bHkgdW5hd2FyZSBvZiBteSB3b3JrIGFuZCByZWxpZWQgb24g aGlzIGV4dGVuc2l2ZSBleHBlcmllbmNlLiAgQnV0IGluIHRoZSBmaW5hbCBhbmFseXNpcyBo aXMgY2hvaWNlcyB3ZXJlLCBJIGJlbGlldmUsIGp1c3QgYXMgYXJiaXRyYXJ5IGFzIG1pbmUu DQo+IA0KPiBXZSBkaWQgbm90IGVuZCB1cCB3aXRoIGFncmVlbWVudCBvbiBob3cgdG8gY29u dGludWUuICBJdCBzZWVtZWQgb2J2aW91cyB0byBtZSB0aGF0IGV2ZXJ5b25lIHdvdWxkIGJl IGJldHRlciBzZXJ2ZWQgYnkgaGF2aW5nIG9uZSBkZWZpbml0aW9uIHJhdGhlciB0aGFuIHR3 byB3aGVuIG5laXRoZXIgd2FzIGZ1bmRhbWVudGFsbHkgc3VwZXJpb3IuICBJZiBwcmVjZWRl bmNlIHdhcyBjb25zaWRlcmVkIGltcG9ydGFudCwgdGhlbiBteSAxOTgxIHB1YmxpY2F0aW9u cyBtaWdodCBoYXZlIGJlZW4gdGhlIHByZWZlcnJlZCBjaG9pY2UsIGJ1dCBJIHdhcyBub3Qg YW5kIHN0aWxsIGFtIG5vdCBzdXJlIGhlIGRpZG4ndCBoYXZlIHNvbWUgcHVibGlzaGVkIHdv cmsgaW4gd2hpY2ggaGlzIGNob2ljZSBoYWQgYmVlbiB1c2VkIGJlZm9yZSAxOTgxLiAgT24g dGhlIG90aGVyIGhhbmQgaW1wbGVtZW50YXRpb24gb2YgY29tcGxleCBudW1iZXIgQVBMIHN5 c3RlbXMgZGlkIG5vdCBoYXBwZW4gcmlnaHQgYXdheSwgd2hlcmVhcyB0aGUgSFAgY2FsY3Vs YXRvcnMgdXNpbmcgS2FoYW4ncyBkZWZpbml0aW9ucyB3ZXJlLCBieSB0aGUgdGltZSB3ZSB0 YWxrZWQsIGFscmVhZHkgZGVzaWduZWQgYW5kLCBhcyBJIHJlY2FsbCwgYXZhaWxhYmxlIGZv ciBwdXJjaGFzZS4gIFNvIGluIHRlcm1zIG9mIGdldHRpbmcgdG8gbWFya2V0IGZpcnN0LCBo aXMgZGVmaW5pdGlvbiBzaG91bGQgYmUgcHJlZmVycmVkLg0KPiANCj4gSSBiZWxpZXZlIHRo ZSBMSVNQIGNvbW11bml0eSBmZWx0IHNpbWlsYXJseS4gIExhdGVyLCB3aGVuIEd1eSBTdGVl bGUgYW5kIEkgc3Bva2UsIEkgaGFkIHRvIGFncmVlIHRoZWlyIGNob2ljZSBmb3IgQ29tbW9u IExJU1Agd2FzIHJlYXNvbmFibGUsIGFuZCB0b2xkIGhpbSBzby4gIA0KPiANCj4gVGhlIG9u ZSB0aGluZyB0aGF0IEkgZGlkIG5vdCBkbyBhdCB0aGUgdGltZSBhbmQgc2hvdWxkIGhhdmUs IHdhcyB0byBwdWJsaWNseSBlbmRvcnNlIEthaGFuJ3MgY2hvaWNlIGFuZCByZWNvbW1lbmQg dGhhdCBBUEwgaW1wbGVtZW50YXRpb25zIGRpc2NvbnRpbnVlIHVzaW5nIG1pbmUuICBJIGRv IHJlZ3JldCB0aGF0IGFuZCBjYW4gb25seSBleGN1c2UgaXQgYnkgc2F5aW5nIHRoYXQgbXkg aW50ZXJlc3RzIGhhZCBieSB0aGF0IHRpbWUgY2hhbmdlZCBhd2F5IGZyb20gQVBMIHRvIG90 aGVyIHRoaW5ncyBpbmNsdWRpbmcgVkxTSS4gIE9mIGNvdXJzZSB0aGF0IGlzIG5vdCBhIHZh bGlkIGV4Y3VzZS4gIFBlcmhhcHMgdGhpcyBub3RlIGNhbiBub3cgc2VydmUgdGhhdCBmdW5j dGlvbi4gIEl0IGlzIG9ubHkgMzUgeWVhcnMgdG9vIGxhdGUuDQo+IA0KPiANCj4gT24gV2Vk bmVzZGF5LCBOb3ZlbWJlciAxMSwgMjAyMCBhdCAxMDo1NTowMyBBTSBVVEMtNSwgQm9iIFNt aXRoIHdyb3RlOg0KPj4gT24gMTAvMjcvMjAyMCAzOjU4IFBNLCBSb2dlciBIdWkgd3JvdGU6 IA0KPj4+IFRoZSBEeWFsb2cgaW1wbGVtZW50YXRpb24gZm9sbG93cyBQZW5maWVsZCAxOTgx IChfUHJpbmNpcGFsIFZhbHVlcyBhbmQgQnJhbmNoIEN1dHMgaW4gQ29tcGxleCBBUExfLCBo dHRwczovL2RvaS5vcmcvMTAuMTE0NS84MDAxNDIuODA1MzY4KSwgZXF1YXRpb24gMTI6IA0K Pj4+DQo+Pj4gYXJjdGFuaOKGkHvijZ8oMSvijbUpw5cow7cxLeKNtSoyKSowLjV9IA0KPj4+ DQo+Pj4gYXJjdGFuaCDCrzIgDQo+Pj4gwq8wLjU0OTMwNjE0NDNKwq8xLjU3MDc5NjMyNyAN Cj4+Pg0KPj4+IMKvNyDil4sgwq8yIA0KPj4+IMKvMC41NDkzMDYxNDQzSsKvMS41NzA3OTYz MjcNCj4+IFRoZXJlIGlzIHNvbWUgZGlzYWdyZWVtZW50IGFib3V0IFBhdWwgUGVuZmllbGQn cyBjaG9pY2UgaW4gaGlzIDE5ODEgDQo+PiBwYXBlciBvZiBicmFuY2ggY3V0IGRpcmVjdGlv biAoQ1cgdnMuIENDVykgb24gYXJjdGFuIChhbmQgYnkgZXh0ZW5zaW9uLCANCj4+IGFyY3Rh bmgpIHdpdGggd2hpY2ggSSBhZ3JlZS4gRm9yIGEgbW9yZSBkZXRhaWxlZCBhbmFseXNpcywg c2VlIEthaGFuWzFdIA0KPj4gKHNlYXJjaCBmb3IgIkFQTCIpIGFuZCBTdGVlbGVbMl0uIA0K Pj4NCj4+IFRoZSBsYXR0ZXIgcmVmZXJlbmNlIHJlY29tbWVuZHMgdGhlIGRlZmluaXRpb25z IA0KPj4NCj4+IGF0YW4g4oaQeygo4o2fMSvijbXDlzBKMSkt4o2fMS3ijbXDlzBKMSnDtzBK Mn0gDQo+PiBhdGFuaOKGkHsoKOKNnzEr4o21ICkt4o2fMS3ijbUgKcO3IDJ9IA0KPj4NCj4+ IE1vcmUgaW1wb3J0YW50bHksIG5vdGUgdGhhdCBTdGVlbGVbMl0gZW5kcyB3aXRoIHRoZSBm b2xsb3dpbmcgc2VudGVuY2U6IA0KPj4NCj4+ICJQYXVsIFBlbmZpZWxkIG9mIE1JVCwgYWZ0 ZXIgd2hvc2UgYXJ0aWNsZSB0aGUgQ29tbW9uIExpc3AgYnJhbmNoIGN1dHMgDQo+PiB3ZXJl IG9yaWdpbmFsbHkgcGF0dGVybmVkLCBlbmRvcnNlcyB0aGlzIGNoYW5nZS4iIA0KPj4NCj4+ IElmIHlvdSBhY2NlcHQgdGhlIGFyZ3VtZW50IHRvIHVzZSB0aGUgb3RoZXIgYnJhbmNoIGN1 dCBkaXJlY3Rpb24gb24gYm90aCANCj4+IGFyY3RhbiBhbmQgYXJjdGFuaCwgdGhlbiB0aGUg YWJvdmUgZm9ybXVsYXRpb24gb2YgYXJjdGFuaCB5aWVsZHMgDQo+Pg0KPj4gYXRhbmggwq8y IA0KPj4gwq8wLjU0OTMwNjE0NDNKMS41NzA3OTYzMjcgDQo+Pg0KPj4gd2hpY2ggcHJvZHVj ZXMgdGhlIHJlc3VsdCAob24gdGhlIHBvc2l0aXZlIGltYWdpbmFyeSBheGlzKSBjaG9zZW4g YnkgDQo+PiB2YXJpb3VzIGltcGxlbWVudGF0aW9ucyBpbmNsdWRpbmcgTkFSUzIwMDAsIEFQ TDIsIEdOVSBBUEwsIEosIENvbW1vbiANCj4+IExpc3AsIEdTTCwgTVBDLCBPY3RhdmUsIGFu ZCBXb2xmcmFtIEFscGhhLiBPbmUgc21hbGwgcmVhc29uIEkgcHJlZmVyIA0KPj4gdGhlIGZv cm0gaW4gYXRhbmggaXMgdGhhdCBpdCBkb2Vzbid0IHJlbHkgdXBvbiB0aGUgZGVmYXVsdCBj aG9pY2Ugb2YgdGhlIA0KPj4gcG9zaXRpdmUgcmVzdWx0IG9mIHNxdWFyZSByb290IHRoYXQg YXJjdGFuaCB1c2VzLCBidXQgdGhpcyBpcyBub3QgYSBiaWcgDQo+PiBkZWFsLiANCj4+DQo+ PiBJIGRvbid0IGtub3cgdGhlIHJhdGlvbmFsZSBiZWhpbmQgb3RoZXIgaW1wbGVtZW50YXRp b25zLCBidXQgdGhpcyBpcyB3aHkgDQo+PiBOQVJTMjAwMCBwcm9kdWNlcyB0aGF0IHJlc3Vs dC4gDQo+Pg0KPj4gUmVmZXJlbmNlcyANCj4+DQo+PiBbMV0gS2FoYW4sIFcuICJCcmFuY2gg Q3V0cyBmb3IgQ29tcGxleCBFbGVtZW50YXJ5IA0KPj4gRnVuY3Rpb25zLCBvciBNdWNoIEFk byBBYm91dCBOb3RoaW5nJ3MgU2lnbiBCaXQiIA0KPj4gaW4gSXNlcmxlcyBhbmQgUG93ZWxs IChlZHMuKSAiVGhlIFN0YXRlIG9mIHRoZSBBcnQgDQo+PiBpbiBOdW1lcmljYWwgQW5hbHlz aXMiLCBwcC4gMTY1LTIxMSwgQ2xhcmVuZG9uIA0KPj4gUHJlc3MsIDE5ODcsIGh0dHBzOi8v cGVvcGxlLmZyZWVic2Qub3JnL35kYXMva2FoYW44NmJyYW5jaC5wZGYgDQo+Pg0KPj4gWzJd IFN0ZWVsZSwgIkNvbXBsZXggQVRBTiBCcmFuY2ggQ3V0IiANCj4+IGh0dHA6Ly9jbGhzLmxp c3Auc2UvSXNzdWVzL2lzczA2OV93Lmh0bSANCj4+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fIA0KPj4gQm9iIFNtaXRoIA0KDQo=

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)