[Octave-bug-tracker] [bug #60055] regarding to bug #15872: atanh branch cut strangeness

[Rik]

Update of bug #60055 (project octave):

                  Status:                    None => Wont Fix               
             Open/Closed:                    Open => Closed                 
        Operating System:       Microsoft Windows => Any                    

    _______________________________________________________

Follow-up Comment #2:

Choices about which phase factor to use are exactly that: choices.  Fortran
and Mathematica may have made one choice, but Octave seeks to be
Matlab-compatible so we need to follow whatever choice The Mathworks made.  In
this case, Matlab gives


atanh (3)
ans = .3466 + 1.5708i


You can see below that the difference in choosing the phase results in an
error term that is on the order of machine precision, so that's as good as
numerical methods, as opposed to pure math, can get.


octave:4> tanh (.3466 + pi/2i)
ans =  2.9998e+00 - 4.8978e-16i
octave:5> tanh (.3466 - pi/2i)
ans =  2.9998e+00 + 4.8978e-16i


In either case the value is an appropriate inverse of the tanh function
because x - tanh(atanh(x)) is approximately zero.

Another way to think about this is to consider the sqrt function.  The sqrt
function is the inverse of the squaring function.  So if I define


fsqr = @(x) x.^2;


then there is an inverse function finv such that x = finv (fsqr (x)).  For
fsqr(), that inverse function is sqrt().  But, sqrt() can return two possible
values.  For example, sqrt(25) = -5 is correct because -5^2 = 25.  Likewise,
sqrt(25) = 5 is correct because 5^2 = 25.  Either answer is acceptable, and it
is simply a choice that most mathematical programs make to return the answer
with the positive phase factor.

One further point, the Mathematica calculation uses the identity log (x + y) =
log (x) - log (y).  This is true for pure math, but only approximately true
when using a computer where there is finite precision and round-off error. 
One thing that helps reduce errors is to use similarly sized numbers.  The
value (1 + z) / (1 - z) will be calculated more accurately because the
numerator and the denominator are of near equal magnitude.  You can check this
with the following calculation


octave:15> z = 1e6;
octave:16> zobs = abs (tanh (0.5*(log (1+z) - log (1-z))))
zobs = 1.0000e+06
octave:17> zobs - z
ans = -1.3944e-04


But Octave's version of the atanh function reproduces the original Z value
more accurately.


octave:18> zobs = abs (tanh (atanh (z)))
zobs = 1000000
octave:19> zobs - z
ans = 0


Marking as "Won't Fix" and closing report.






    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?60055>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/