tanh is defined to be sinh/cosh.
And the unexpected spike is a result of a bug in the division routine.
More precisely, the macro \pgfmathdivide@@ defined in
pgfmathfunctions.basic.code line 10 (github link)
contains an unwanted behavior.
\pgfmathdivide@@
This macro uses \pgfmath@x (numerator) and \pgfmath@y (denominator)
to implement long division.
Here is the pseudo code
While (x > δ & y > δ):
If x < y:
append and `0` at the end of \pgfmathresult;
divide y by 10;
Else: %%% x ≥ y
compute a:= floor(x/y);
If a is single digit:
append that digit at the end of \pgfmathresult;
subtract y by x * a
Else: %%% in this case we always have 10 ≤ a < 20
subtract a by 10
depending on how many digits \pgfmathresult has, add 10^-d to \pgfmathresult
append a to the end of \pgfmathresult
You see that the code becomes nasty when x/y ≥ 10.
Usually, you would expected that x/y is always less than 10
because the previous y (the y before it was divided by 10)
is less than x and the single-digit branch will be executed.
So this branch is never executed;
it doesn't matter if the code is ugly.
But that is not true.
What could go wrong?
Thanks to finite precision, the following could happen
- (x, y) = (0.00037, 0.00038) so the x < y branch is executed;
y is divided by 10.
- now (x, y) = (0.00037, 0.00003) so the x > y branch is executed;
now floor(x/y) = 12 ≥ 10
"Fine," you might say.
Since 0.00038 -> 0.00003 only happens when
\pgfmathresult already has many digits,
adding 0.000012 or 0.00009 doesn't really matter.
Except that it sometimes does.
You see, adding 10^-d to \pgfmathresult isn't an easy job
because 0.001 + 0.999 includes carrying.
So instead of textually manipulating \pgfmathresult,
this is done by
- converting
\pgfmathresult to a TeX dimension (\pgfmath@xa),
- adding
1pt, 0.1pt, ..., or 0.00001pt,
- and then converting TeX dimension back to text.
The problem is, if \pgfmathresult is 0.99999,
then the result of adding 0.00001pt to 0.99999pt is 1pt, not 1.00000pt.
Recall that we are in the a ≥ 10 branch
and we will append a - 10 at the end of the new \pgfmathresult.
So if a = 12, we will get 1.2 as the result, not 1.000002.
Fix
I don't know how to fix this.
\pgfplotsset{compat=newest}the problem still remains. I have updated the code accordingly. Thanks for the new "problem variable". – Dr. Manuel Kuehner Aug 22 '21 at 00:17tanh(6.656) = 1Y1.2e0]. – Symbol 1 Aug 22 '21 at 02:09