On Jan 1, 2010, at 2:08 PM, TimDaly wrote: >> 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.
Yep. It also tells the user that there may be some numerical noise. > 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. By adding the ... for the trailing digits, one is explicitly saying that a change in the last couple of digits should not be considered incorrect (e.g. it varies in inconsequential ways depending on the platform), thus reducing the false positive rate for your regression tests. In my mind this makes for a better 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. It is both intuitive to read and standard use in the Python doctesting framework, which makes it a nice fit for us. > See http://www.diycalculator.com/popup-m-round.shtml Given that most of the people on this thread don't actually use Sage, I'd like to point out that both of these failing tests have to do with the handling of Python floating point numbers, which are basically C doubles and inherently have all the same advantages and disadvantages. By default, when one works with floating point numbers in Sage MPFR values are used, which (modulo MPFR bugs) are bit-for-bit identical on all supported platforms and as accurate as possible (with your choice of rounding mode) to the last bit. Of course this has a speed penalty, which is why we try to make sure things work smoothly with python floats as well. - Robert -- 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
