On Friday, 3 February 2012 09:28:37 UTC+8, Jonathan Bober wrote: > > On Thu, Feb 2, 2012 at 3:05 PM, rjf <> 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. >
oh well, surely for gamma doubling the precision does the trick... At least for x=151 one would get the relative precision of expl(lgammal(x)) down to <10^{-13} for for x=6 down to <10^{-18} > > 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