Sign up ×
Mathematica Stack Exchange is a question and answer site for users of Mathematica. It's 100% free, no registration required.

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

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

enter image description here

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.

share|improve this question
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

2 Answers 2

up vote 7 down vote accepted

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.


The example has been reevaluated in the documentation as of Mathematica 10.3. enter image description here

share|improve this answer
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 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 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

share|improve this answer
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

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.