On Thu, Aug 5, 2010 at 7:13 PM, Carl Witty <carl.wi...@gmail.com> wrote: > On Thu, Aug 5, 2010 at 2:59 PM, Dr. David Kirkby > <david.kir...@onetel.net> wrote: >> On 08/ 5/10 06:17 PM, Sergey Bochkanov wrote: >>> >>> Hello, >>> >>>> Hmmm... Didn't thought about this situation yet. Definitely we can't >>>> solve this problem with any kind of regular expressions. One >>>> possible solution is to round data before printing. So both >>>> 1.00000000000001 and 0.99999999999999 will become 1.000000. >>> >>> ...however, we still can have problems when rounding X=0.000499999 up >>> to three digits. With original X we will have 0.000. But with >>> perturbation as small as 0.000000002 we will round to 0.001. >> >> I've never done this, but the most logical thing to me seems to be to look >> at the absolute magnitude of the relative error, for all cases except when >> the expected value is 0. But I guess on cases where the numbers are not >> close to 1, or other special cases one could think up, the current system is >> probably the simplest. > > That would be nice. But it's a bit tricky to write, since the doctest > check happens solely on the basis of string comparison; to do > something clever like looking at relative error would require some > sort of marking in the expected output to turn on the relative-error > check, and some sort of parser to find the numbers in the > expected/found outputs, and possibly some sort of marking on a > per-number basis in the expected output to say what relative error is > allowed on that number. (If the expected output is 1.23456*x^10000, > with a relative error allowed of 1e-3, you probably don't want to > allow 1.23456*x^10001 !) > > I would be in favor of something like this, if we could decide on a > set of markings in the expected output that didn't interfere too much > with the documentation aspect; but nobody has written it yet. > > The three-dots notation is much, much stupider than this... it is just > a wildcard that will match an arbitrary string of characters (the > equivalent of .* as a regex, or * as shell globbing). And we didn't > even write it; it's a standard part of the Python doctest system.
And the three dots is much prettier to read too. Personally, I just choose doctests whose results are not subject to the 1.0000000000 vs. 0.99999999999 kind of noise, unless I want to make a point that the function nails the result right on (in which case 1.000000000 is a good doctests for that). - 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
