# Erfc Not Returning Results Specified in Documentation

In the documentation for Erfc (under "Possible Issues"), the following command returns a number that is extremely close to 2:

However, when I run this same command in a fresh kernel, I get:

What's going on here? Wrapping the command in N[#, 1000] doesn't seem to help. I'm using Mathematica 8.0.1 on OS X.

-
Wrapping the command in N will help when you remove the decimal point after the $30$. Ask for $407$ digits. – whuber Mar 5 '13 at 4:20

Erfc[-30. + 10^-1 I] used to return the result shown in the documentation through version 7.0.1.

The implementation changed for version 8.0 and it started giving a machine precision answer (which is correct, more consistent and still demonstrates the same possible issue by being very close to 2).

The (documentation) bug is that this example did not get reevaluated to show the new output. Thank you for bringing this issue up, I have reported it to the appropriate team so that the documentation can be corrected.

Update

The example has been reevaluated in the documentation as of Mathematica 10.3.

-
Is it really a fix? This is simply indistinguishable from 2 at machine precision, not merely "very close". I agree with the change in behavior of Erfc but I would rather fix the documentation by putting Erfc[-30.30 + 10^-1 I] as the example. – Oleksandr R. Oct 29 '15 at 23:16
@OleksandrR The behavior is correct and the documentation now matches the behavior, so I declared victory... note the input was always machine precision. Yes, using a bignum input would make a good example too. – ilian Oct 29 '15 at 23:26

I think there is a typo in the documentation. I think they meant to write something like

Erfc[-30.20 + 10^-1 I]


which gives

1.99999999999999999999999999999999999999999999999999999999999999999999\ 9999999999999999999999999999999999999999999999999999999999999999999999\ 9999999999999999999999999999999999999999999999999999999999999999999999\ 9999999999999999999999999999999999999999999999999999999999999999999999\ 9999999999999999999999999999999999999999999999999999999999999999999999\ 9999999999999999999999999999999999999999999975103622845528878 + 7.155170950793436*10^-394 I

-
There does appear to be some kind of a typo, but it is curious that the given answer in the docs looks like it should correspond to somewhere between $16$ and $17$ decimal places--almost exactly the native precision. It seems there might be something else going on here. – whuber Mar 5 '13 at 4:52