Maxima is printing what I consider a strange result on two Solaris machines,
when computing the
asinh of 1.0. The leading zero is not printed, so a doctest
fails.
sage: maxima('asinh(1.0)')
.8813735870195429
which fails a doctest
Expected:
0.881373587019543
Got:
.8813735870195429
http://trac.sagemath.org/sage_trac/ticket/9693
The Maxima developers can reproduce similar examples on Linux machines and seem
to see this more as a feature than a bug, as it allows printing more digits in
the 17 places allocated to printing numbers.
http://www.math.utexas.edu/pipermail/maxima/2010/022230.html
How should this doctest be changed so it passes?
What seems easiest to me, is just to change the test. So instead of finding the
asinh of 1.0, we do it of 2.0
sage: maxima('asinh(2.0)')
1.44363547517881
That gives a number > 1, so the problem with the missing leading zero goes. For
the point of view of a test, I don't see it really matters what the value is
going to be chosen.
A higher precision result of this, which I computed with Mathematica is:
In[4]:= N[ArcSinh[2],30]
Out[4]= 1.44363547517881034249327674027
It so happens I get *exactly* the same result then on all these machines.
* sage.math (Linux)
* bsd.math (OS X)
* t2.math (Solaris 10 on SPARC)
* fulvia @ skynet (Solaris 10 on x86)
* My Ultra 27 (OpenSolaris on x86)
In all cases, all digits are in fact correct - at least they agree with a higher
precision result I computed with Mathematica.
So I propose we change symbolic/expression.pyx to compute the asinh(2.0) instead
of asinh(1.0), and set the expected result to 1.44363547517881, as that's that
result is correct in every digit, and is given on all the machines where I have
managed to try Sage.
Does that seem a reasonable change?
Perhaps setting the expected result to 1.4436354751788... might be better, as
that will allow a bit of room for numerical noise, though all machines I've
tested on give exactly the same result.
Dave
