On Feb 2, 5:28 pm, Jonathan Bober <jwbo...@gmail.com> wrote: > 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?
I don't require that integer arguments be treated in a special way, just that the algorithm used return correct values for integers (that is, as integers). How would you feel about a routine that computed cos() within a unit in the last place or so, but did not get cos(0.) = 1.00 exactly? A good testing regime for scientific subroutines requires correct answers to key arguments, like cos(0.) or in this case, gamma(integer). There are other such properties you want from a routine, for example that the routine is monotonic where the function is monotonic. (That is, the subroutine does not have spurious maxima or minima.) > 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. I think you miss the point that bad answers are harmful in ways that you cannot anticipate easily. Speed is not job one. > > > 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. The IEEE 754 committee report does not deal with special functions. There are reasonable quality implementations of special functions in various places, I think. I don't know about the ones used by Sage. > 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. search for "table maker's dilemma". Just because one cannot easily predict the time to compute a correctly rounded result in all cases does not mean (a) it takes a long (or infinite) time. (b) you shouldn't try to return a correct answer. MPFR for example, claims to do so. (c) a goal of 1 ulp or less is commonly stated for systems with the capability of doing arithmetic in higher precision than the delivered precision. e.g. double- extended arithmetic to get correctly rounded double. > > 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). In my casual testing of MPFR, I found that either the claims were exaggerated, or maybe I was printing one or more digits than the binary representation provided. >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. Based on what? Have you studied numerical analysis, scientific computation, etc.? I don't know you at all, but in my experience, people with a modest exposure to a computer programming language tend to make many pronouncements of what scientific routines should or should not do without much hesitation, assuming it's kind of "who cares anyway". Just taking your statement at face value, do you really think that it is OK for 2 people using Sage on 2 different computers should be able to run the exact same program and get 2 different answers, like "this computation shows there is water on Mars" and "nope...". Numbers that seem to be nearly right get to be very wrong after only one operation, sometimes. consider the operation "round upward to the nearest integer" and apply it to gamma() output. > (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.) I would not have thought that you would consider this acceptable. Would you also accept a system in which 2+2 is unreliable? -- 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
