Le 03/02/2012 02:28, Jonathan Bober a écrit :
On Thu, Feb 2, 2012 at 3:05 PM, rjf <fate...@gmail.com
<mailto:fate...@gmail.com>> wrote:
I don't know about arithmetic on ARM specifically, but there is
something
wrong with a gamma() function that fails to return an integer (perhaps
in float format) when it is
given an integer argument (perhaps in float format), and the answer is
exactly representable
as an integer in float format.
I'm not sure that I agree. It would certainly be nice if gamma() worked
this way, but when you consider implementation issues, do you really
want to treat integer arguments in a special manner? If there is a
reasonable implementation that can guarantee this behavior with no loss
in speed and no other significant trade-offs, then library designers
should use it, but I don't think that it is such a simple issue.
+10^{10} !
It would also be nice if any floating-point tests that you ran with
Sage
either (a) determined IEEE 754 standard compatibility and
tested numerical routines subject to that standard, or
(b) determined machine parameters (e.g. machine epsilon etc.)
and the tests were written so as to take variations into
account.
RJF
Are there IEEE 754 standards for the accuracy of special functions? I
tried finding some, but I could not. As far as I know, the standards do
not specify that transcendental functions need to be computed with the
same accuracy that one expects from basic arithmetic operations, because
it is essentially unknown how much memory/time would be needed for this
in all cases.
For the four failing numerical tests on ARM :
- three of them are good within a relative error tolerance of 1e-15
- one of them is good within a relative error tolerance of 1.2832..e-15
I'm definitely sure the first three should be just "# tol rel" away ;
for the fourth one, I don't know, for the same reason : I don't know
what is the official expectation...
In Sage, RealField uses mpfr as its backend, and hence its special
functions should always be computed accurately with correct rounding
(and thus by definition its results should be independent of the system
sage is running on). However, python floats map to hardware types and as
such, I think that it is perfectly reasonable if certain operations with
floats depend on the underlying hardware, the operating system, the
specific libraries that are present, and perhaps the phase of the moon.
(And I think that computing the gamma function is probably one of these
cases. Yes, in case you are wondering, I would probably consider it
acceptable if gamma(float(6)) did not even always give the same answer
every time it is run in the same sage session.)
+1 A user asking for a floating-point computation means (s)he is ready
to accept the results are mathematically wrong, but computationally
within a reasonable error range.
Snark on #sagemath
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
