On Fri, Jan 1, 2010 at 2:18 PM, Dr. David Kirkby <david.kir...@onetel.net> wrote: > TimDaly wrote: > >> 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 > > I must admit, it had crossed my mind that truncation like this was not > optimal. > Even without reading the reference, I would have thought something like > testing ifL > > abs(expected - got) < some_tolerable_absolute_error > > may have been a better choice. > > Truncating is obviously going to be a problem if the expected number is > 1.000000000000000 but you get 0.9999999999999999 Those two numbers are fairly > close in value, yet their digits are completely different. > > Perhaps I'm missing something here.
The test we're talking about right now are "doctests". There primary purpose is to serve as *documentation*... that is actually correct. As such, changing lines such as sage: foo(bar) # last few digits numerically unstable 1.23... to sage: abs(foo(bar) - 1.23) < 0.00001 True would be a step backwards. It would be a step backwards, because it is harder to read and expresses less clearly what the documentation is supposed to illustrate (which is how to use the function foo). Test like your suggestion above would make perfect sense as unittests or in the context of randomized testing. Those are great, there are some in Sage, but they serve a different purpose than doctests. William -- 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
