There are as I see it two problems here with this test.
1) Do we know what a value for a high-precision result? I get rather frustrated
seeing doc tests where the only justification given for a result seems to be
"what I got with my computer".
2) Assuming the "expected" result is correct, then the value "got" on Solaris
has a relative error of
In[12]:= (-9.0604285688230899+9.0604285688230917)/-9.0604285688230899
-16
Out[12]= -1.96057 10
A relative error 1.96 x 10^-16 does not seem unreasonable to me for double
precision floating point maths. You can't generally expect to better.
However, assuming we permit a doctest of -9.0604285688230..., then a value of
-9.0604285688230 would be acceptable.
That's a relative error of
In[13]:= (-9.0604285688230899+9.0604285688230)/-9.0604285688230899
-15
Out[13]= 9.99889 10
which is 51 times worst!
In other words, in this case, to permit a small amount of numerical noise (~ 2 x
10-16), we would have to permit more than 50x what we actually got. That's why I
asked John about this test, as doing that does not seem reasonable to me.
It would be really good if we know what the exact (or at least a high precision
result was though). I really hate tests where the reason for the chosen number
seems only based on what someone got on their machine.
Dave
I'm the upstream author of 100% of this code, and know precisely what
it does, which is a sequence of floating point ops and calls to the
math library, which *of course* can be machine dependent.
Put in dots.
-- William
Thank you Yann.
Dave