That particular fix is still unreleased, merged mid February 2015.

Yep, fixed now. Closing this, but I added it to the 1.9.3 milestone just in case we make that release.

With numpy 1.11.2+mkl and Python 3.5.2 I'm seeing this same problem still. Here's the output from my PyCharm console:

Python 3.5.2 (v3.5.2:4def2a2901a5, Jun 25 2016, 22:01:18) [MSC v.1900 32 bit (Intel)] on win32
In[2]: from numpy import *
x=(616.47292227535877+53.814558958179042j)
In[3]: tanh(x)
Out[3]:
D:\Program Files (x86)\JetBrains\PyCharm Community Edition 2016.2.3\helpers\pydev\pydevconsole.py:1: RuntimeWarning: overflow encountered in tanh
'''
0j

Needless to say, I see the problem with other large complex numbers too, not just mieswichts' magic number. :-)

@CarpeCimex: where exactly are you getting numpy from? anaconda?

I got it as a wheel from Christopher Gohlke at http://www.lfd.uci.edu/~gohlke/pythonlibs/ and installed it with pip. Here's a version check:

Python 3.5.2 (v3.5.2:4def2a2901a5, Jun 25 2016, 22:01:18) [MSC v.1900 32 bit (Intel)] on win32
In[2]: import numpy
In[3]: numpy.version
Out[3]:
'1.11.2'

I still had the problem with numpy 1.9.1 when i checked it right now (never removed my redefinition of tanh), but when I pip upgraded to numpy 1.11.2 , it works fine now.

Python 3.4.2 (v3.4.2:ab2c023a9432, Oct 6 2014, 22:16:31) [MSC v.1600 64 bit (AMD64)] on win32
Type "copyright", "credits" or "license()" for more information.

from numpy import *
x=(616.47292227535877+53.814558958179042j)
tanh(x)
(1+0j)

I still vote for an inclusion of coth though.

http://mathworld.wolfram.com/HyperbolicCotangent.html

I had to use the "+mkl" version of numpy to work with another package.
@mieswicht: is yours +mkl? Also, it looks like your Python is 64 bit AMD (on win 32?), while mine is 32-bit. That difference might have something to do with it working on yours and not mine.

No, I dont use +mkl and my machine is 64-bit as is my python.

I'm experiencing RuntimeWarning: overflow encountered in tanh when using sympy's lambdify to turn a sympy expression into a numpy array. Numpy version 1.14.3 with mkl.

I'm dealing with relatively large numbers, at least up to 1e13 (this is what survives the overflow warning).
Here is a traceback of the warning, for anyone interested.

Edit: To reproduce: np.tanh(1e15*(1 + 1j))

Hi, I am in np.version 1.19.2 and this is still a thing.

What platform?

Hi,

This bug is very much still in the wild - reproducible on win x64 in python 3.9.x and np 1.20.x

Related issue:
simpeg/simpeg#1042

I've tested with both mkl and openblas versions via Conda and both produce overflow warnings.

Cheers,
N

Bug still there - I'm on a win x64 with python 3.9.x and np 1.21.x. The problem occurs when using the tanh**-1 definition of coth. However, with the same code I don't experience the warnings on my linux. I dunno.

I'm having the same problem when using impedance.py. I'm using Python 3.10.6, Numpy 1.23.3 on a Windows PC.

RuntimeWarning: overflow encountered in tanh
  Z = Z0/(np.sqrt(1j*omega*tau)*np.tanh(np.sqrt(1j*omega*tau)))

@pililac Where did you get NumPy?

I think MSVC has no complex support (that is basically not implementing C99 completely). I am not quite certain about newer versions.
Also, I think it may have complex support in C++ mode, so that might be a solution?

Right now, I expect we are using fallback versions on MSVC and those do not have branches to deal well with large values.

@pililac Where did you get NumPy?

I installed it via conda using miniforge. Here is a partial view of conda list:

(data_analysis) C:\Users\user_01>conda list
# packages in environment at C:\other_software\miniforge3\envs\data_analysis:
#
# Name                    Version                   Build  Channel
...
numpy                     1.23.3          py310h4a8f9c9_0    conda-forge
...

OK, if you start something have to look it through I guess. After almost setting up windows, I realized that godbolt does the trick:
https://godbolt.org/z/Trz4sxhn3

Which shows that we are using the MSVC/system math version when the result is 0. The version that NumPy would be using as a fallback does return 1+0j for the example.

I am not sure if the right solution is to just consider this an MSVC/windows math issue or whether we should blocklist MSVC for ctanh and use our own version.

@seberg We should establish if the conda version is using MKL, which may have its own libraries. Once we determine which library is failing we should file a bug upstream and use the fallback version, which should be OK since we don't have extended precision on windows.

@charris I am not aware that MKL can replace math functions at run-time for scalars values (or even provides those)? (Unless this was patched by Intel, but those patched versions seem to not really be used much anymore.)

We do have SIMD versions for tanh actually (roughly based on the SVML algorithm). But that version does seem to have the correct checks for large inputs.

Sounds like we should just blocklist. I agree that it should be filed as a bug upstream, I will try to do it. Last time, I didn't because they are very restrictive about requiring and making things public, but...

Hmmm, I reported an issue, not sure if in the right place, since the C++ version std::tanh actually does the right thing in MSCV, it is just the C99 version that is wrong: https://godbolt.org/z/aoxEqnEnj

Ah, interesting tidbit maybe. And something that I guess the previous comments also point to: The issue only reproduces with x86 mode on godbolt (I got lucky to pick that first...) and not x64.