> That is to say, if the Sage > documentation says: > > sage: foo(bar) > 1.2345 > > but in fact in Sage one has > > sage: foo(bar) > 1.2351 > > then I would consider this misleading documentation, i.e., a bug. > Your statement above suggests that you *don't* consider this a bug at > all. In Sage, one possible solution (and it depends on context > whether this it the right solution or not) would be to change the > documentation to > > sage: foo(bar) # last few digits numerically unstable > 1.23... >
The idea of documentation is that the user can see what to expect when typing a command. Your result 1.23... achieves this goal. The idea of regression test is to detect changes in results that are incorrect. If you do a computation on a system and the result differs in the trailing bits (due to a real bug) then your regression test f() = 1,23... will succeed. So representing the result f() = 1.23.... will not detect a bad computation if the new library has a bug and is, at best, a weak regression test. All non-bit floating point output involves a choice of rounding. You have chosen to do rounding by truncation. This choice is not obvious nor necessarily the best. See http://www.diycalculator.com/popup-m-round.shtml In any case, you're welcome to test any way you prefer. I just thought I'd give you insights from Axiom's tests. I'll let it rest. Tim -- 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
