On Sat, Feb 4, 2012 at 8:13 AM, rjf <fate...@gmail.com> wrote: > > > > 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. >
No, I am not missing that point at all. I am simply trying to point out that there are many issues to consider. Suppose there are two implementations which compute some function f. If the first has the property that it is always correct to with 5ulp, and the second has the property that it is always correct to .5 ulp, but the second takes 5 times longer to run than the first, then there is no answer to the question of "which is better?" It depends entirely on desired usage. If you are writing a higher level function that uses f() as input, then you can make a choice of which behavior you prefer, but if you are writing a OS level library that is going to be the default for anyone who doesn't make a choice, then it is not clear which implementation you should choose. [...] > > 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". That is, of course, exactly what I was referring to. I may have exaggerated a bit, and perhaps 1 ulp is obtainable even when .5 ulp might not be. 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...". > > In some cases, yes, I think that would be OK. Your example is extreme, but if somehow the consistency would come down to the evaluation of a transcendental function on a primitive type that maps directly to a hardware type being the same on both platforms, then that program is probably doing something wrong. Some things should be the same on all platforms, like arithmetic with elements of the RealField. Some things might vary, like arithmetic with python floats. > Would you also > accept a system in which 2+2 is unreliable? > > Probably not, as that is much different. But on some machines, e.g. x86 with extended precision enabled in the FPU, a JIT compiler might change the results of a function that uses floating point arithmetic from one function call to the next, as compilation might change when intermediate results get rounded. And with gcc, results of floating point arithmetic can change depending on optimization, even without -funsafe-math-optimizations. I view these things as acceptable, and if I am writing code that depends on consistency I take them into account. Anyway, this aspect of the conversation has probably gone on too long. Maybe I'll have to sign up for sage-flame if I feel like continuing it. -- 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
