On Thu, Feb 2, 2012 at 3:05 PM, rjf <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.
> 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. 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.) -- 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
