Hi Bjarke,

If I understand your goal, this could be a typical use case of generic
category testing. Whenever you have a monoid M and you run:

        sage: TestSuite(M).run()

the associativity of M is tested (by M._test_associativity()).  We do
not yet have a PolynomialRings category, but we should. And this
category should provide some generic tests.

Which polynomial rings are actually tested is determined by which ones
appear in a TestSuite(...).run() in the Sage doctests. Ideally, this
should be a good sample of all the polynomial rings implemented in Sage.

Please see TestSuite? and sage.categories.primer?, and get back to me
if you need any help!

Best,
                                        Nicolas


On Sun, Feb 28, 2010 at 03:01:58PM -0800, Bjarke Hammersholt Roune wrote:
> Primarily what I'm wondering is if there is already a good way to do
> this, since I'm not volunteering to implement it if there isn't.
> 
> Still, I don't suppose it hurts to mention what I would like. For
> polynomial rings, it would be a function along the lines of
> 
>   makeSomeRing(predicate)
> 
> where predicate is a function mapping rings to true/false, and
> makeSomeRing returns some ring that makes pred evaluate to true and
> throws an exception if it can't find any such ring. Then Sage could
> detect that this method has been called and re-run the test where the
> method returns a different ring each time. Or it could just be run
> once by default for some preferred ring and many times given some
> option to do more exhaustive testing. At the most simple, makeSomeRing
> could just try pred on a fixed list of rings. Add a newly written ring
> to the list as you add it to Sage, and you get the new ring tested in
> every situation where the old rings are already tested. So the intent
> is not to construct random rings, though the scheme could be extended
> to support that as well.
> 
> This scheme applies to just about anything you might wish your test to
> be parameterized by, it's just that rings is what is relevant to me
> for the Frobby interface. Testing the output could be handled by
> constructing the correct answer in the same ring, or by converting at
> the end to some fixed ring. If this were adopted, probably there
> should be a rule that the first test does not use this, so that the
> tests remain useful as documentation.
> 
> -- 
> 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
                                Nicolas
--
Nicolas M. ThiƩry "Isil" <nthi...@users.sf.net>
http://Nicolas.Thiery.name/

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