On Dec 6, 11:15 am, Robert Bradshaw <rober...@math.washington.edu>
wrote:
> On Mon, Dec 6, 2010 at 8:01 AM, David Kirkby <david.kir...@onetel.net> wrote:
> > On 4 December 2010 05:32, William Stein <wst...@gmail.com> wrote:
> >> On Thu, Dec 2, 2010 at 6:40 PM, David Kirkby <david.kir...@onetel.net> 
> >> wrote:
>[*snip*]
> > It's fairly clear in the past that the "Expected" result from a test
> > is what someone happened  to get on their computer, and they did not
> > appear to be aware that the same would not be true of other
> > processors.
>
> Most of the time that's due to floating point irregularities, and then

http://docs.python.org/release/2.6.6/tutorial/floatingpoint.html#representation-error

If the "numerical noise" issue in sage testing has been in controversy
for so long, why not replace all such failing doctests with a warning
(if triggered) promising to convert it to a sensible test (not
dependent on floating point order of operations in hardware or said
base conversion); and dispense with all the vitriol? (Not referring to
any particular persons' vitriol -- I'm an equal opportunity observer
of circumlocution.)

> there's an even smaller percentage of the time that it's due to an
> actual bug that didn't show up in the formerly-used environments. In

How does this help your side of the argument?

> both of these cases the test, as written, wasn't (IMHO) wrong. Not

Why?  If the test is non-deterministic, then you can have false-
positives and false-negatives.  What's a good argument for that if you
can avoid it?  If there are counter-examples (test case scenarios)
that prove you must take a statistical approach, then that would be an
entirely different testing framework.

> I agree, people of all backgrounds can make significant contributions.

http://trac.sagemath.org/sage_trac/ticket/8336

Robert and I had a long off-list discussion on this round() bug.  The
problem IMHO, is not sticking to an interface; the requested invariant
(that the same precision type be returned) is not possible in some
cases.  In other words, the interface/invariants are wrong, not the
test.

Speaking in maths terms, if the relation fails the vertical line test
(and is therefore not a function); why on earth would you call it a
function?

-- 
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

Reply via email to