#10963: More functorial constructions
-------------------------------------+-------------------------------------
Reporter: nthiery | Owner: stumpc5
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-6.1
Component: categories | Resolution:
Keywords: days54 | Merged in:
Authors: Nicolas M. Thiéry | Reviewers: Simon King, Frédéric
Report Upstream: N/A | Chapoton
Branch: | Work issues:
public/ticket/10963 | Commit:
Dependencies: #11224, #8327, | eb7b486c6fecac296052f980788e15e2ad1b59e4
#10193, #12895, #14516, #14722, | Stopgaps:
#13589, #14471, #15069, #15094, |
#11688, #13394, #15150, #15506 |
-------------------------------------+-------------------------------------
Comment (by nthiery):
Replying to [comment:433 SimonKing]:
> Here are the classes and the errors I am getting:
Thanks!
Let me go through a sample of the failures that represent all the
others.
> {{{
> 0 sage.combinat.ncsym.bases.NCSymDualBases AttributeError
Ah right, category_sample() is not looking outside of the
sage.categories.all module. It should. This is now #15696.
Hmm, there will be a bunch of similar categories (basically in each
algebra `A` with several bases). They take `A` as first argument. We
will need to see how to treat them in #15696.
> 1 sage.categories.modules_with_basis.ModulesWithBasis.DualObjects
TypeError
Interesting: we caught a bug. This should be a category over base ring
and it's not. Of course, since this is currently unused, this went
unnoticed.
I added this to #15647.
> 2 sage.categories.algebra_functor.AlgebrasCategory AssertionError
As you mentioned, like a couple others belows, this is not a category, but
an abstract category class.
> 3 sage.categories.additive_magmas.AdditiveMagmas.Algebras AssertionError
Ok, the default an_instance() fail for most functor categoryies
(XXX.Algebras, XXX.Quotients, XXX.CartesianProducts, ...). It's
probably possible to fix all at once.
I put this in #15696 too.
> 32 sage.categories.category_with_axiom.BrokenTestObjects
NotImplementedError
Ok, meant to be broken :-)
> 63 sage.categories.category_with_axiom.SmallTestObjects
NotImplementedError
Oh, right, this old test class is not used anymore! I removed it.
> 107 sage.categories.category_with_axiom.TestObjectsOverBaseRing.Unital
TypeError
Interesting, bug again: they should have been
CategoryWithAxiom_over_base_ring:
{{{
sage: TestSuite(TestObjectsOverBaseRing(QQ).FiniteDimensional()).run()
Failure in _test_category_with_axiom:
Traceback (most recent call last):
File "/opt/sage-git/local/lib/python2.7/site-
packages/sage/misc/sage_unittest.py", line 282, in run
test_method(tester = tester)
File "/opt/sage-git/local/lib/python2.7/site-
packages/sage/categories/category_with_axiom.py", line 1337, in
_test_category_with_axiom
tester.assertIsInstance(self, CategoryWithAxiom_over_base_ring)
File "/opt/sage-git/local/lib/python/unittest/case.py", line 969, in
assertIsInstance
self.fail(self._formatMessage(msg, standardMsg))
File "/opt/sage-git/local/lib/python/unittest/case.py", line 412, in
fail
raise self.failureException(msg)
AssertionError: Category of finite dimensional test objects over base ring
over Rational Field is not an instance of <class
'sage.categories.category_with_axiom.CategoryWithAxiom_over_base_ring'>
}}}
This would have been caught with a TestSuite but there was none. I
just fixed this and pushed.
> 111 <class
'sage.categories.finite_dimensional_modules_with_basis.FiniteDimensionalModulesWithBasis'>
yields instance of <class
'sage.categories.category.JoinCategory_with_category'>
> 113 <class 'sage.categories.modules.Modules.FiniteDimensional'> yields
instance of <class 'sage.categories.category.JoinCategory_with_category'>
Hmm, same gag as for Modules(QQ) -> VectorSpaces(QQ).
> And please don't forget:
> {{{
> sage:
type(sage.categories.category_with_axiom.SmallTestObjects.Connected)
> <type 'int'>
> sage:
type(sage.categories.category_with_axiom.SmallTestObjects.Commutative)
> <type 'classobj'>
> }}}
> which are bugs, too.
Well, they were *voluntary* bugs. I was using those at some point to
test the assertion checks in the code. Anyway, gone with the wind.
About global consistency test w.r.t. consistency tests within the lattice
of super categories:
----------------------------------------------------------------------------------------------
Let's not waste more time on this. You are implementing it, you take
the final decision :-) I just meant to make sure you took into account
the advantages and inconvenient of both approaches (including the
deviation from TestSuite, that discovering the categories in the code
is not immediate, that you need an_instance() to work, and that you
can't make use of the tests to know what are the relevant/interesting
input to feed the category constructor).
> > I am certainly not saying it's not doable. But it introduces some
> > complexity which has to be well motivated.
>
> Are you talking about ''mathematical'' complexity? Then my answer is
that the
> complexity of the underlying local--global problem is there, whether we
want
> it or not. And I'd rather have the complexity dealt with by a
mathematical
> theory (commutative algebra) than by the inspiration of all future
developers
> of categories.
I am speaking of technical complexity, and that for solving what I
believe to be a non issue. As I said, there should be no local-global
problem.
> > So far, I haven't had a single time where I got bothered by that.
>
> With exception of the `Blahs.Unital.Blue` example, you mean...
Well, it's not like it did strike me from behind. I made up this
example voluntarily to shake the system, see how it would behave when
violating the specifications, and document a potential limitation (I
never had an actual use case); and it failed as expected.
> Then consider the axiom `a*b==a*c => b==c` (I don't know an English word
for
> it, thus call it "kürzbar"). There are infinite "kürzbare" rings that
aren't
> division ring (e.g., the ring of integers). However, for finite rings,
being
> "kürzbar" and "division" are equivalent.
>
> So, you have a perfectly symmetric formulation:
> `Rings.Finite.Kürzbar==Rings.Finite.Division`. So, how to choose a
default?
(from a quick googling, that's the cancellation property:
http://en.wikipedia.org/wiki/Integral_domain).
This is not symmetric, because Rings().Division() is a subcategory of
Rings.Kurzbar(). Hence, the system already knows that
Rings().Finite().Division() is a subcategory of
Rings().Finite().Kürzbar(). The interesting part of the theorem, and
that that we need to teach Sage, is really about the reverse
inclusion: namely that, in the context of Rings.Kurzbar, Finite
implies Division. Hence, this theorem is naturally implemented in
Rings.Kurzbar.Finite_extra_super_categories.
> Next, imagine you have several of such symmetric statements. You ''can''
do a
> consistent symmetry break---but that's probably equivalent to chosing a
> monomial order in a polynomial ring.
No: the order is given by the subcategory relation, as above.
> > And
> > second DivisionRings().Finite() would not coincide with
> > Fields().Finite(); and this is the first thing you would test.
>
> Why not?
The purpose of my comment was to demonstrate that, in the current
implementation, if you make a mistake then this mistake is immediately
caught.
> Doing the above (DivisionRings = Fields.Finite) is natural and easy
syntax, and it should be supported.
I agree it is rather natural. I actually tried (hard) to implement
it. But knowingly decided against because not having the tree
structure was making the algorithmic really much more convoluted.
And besides, the current syntax is not unnatural either. Granted, the
name XXX_extra_super_categories is not great, but having to write a
method to model something as important as a theorem is ok to me; if
not just because it gives a natural spot to document and test the
modeling of the theorem. And it's consistent with what we have been
doing everywhere else: the mathematical facts which relate the
category together are implemented in the super_categories methods (and
their variants like extra_super_categories).
> > No I did not do wrong. It does demonstrates *on
> > purpose* a *missing feature*: namely that you currently can't use the
> > Blue_extra_super_categories mechanism in the category where the Blue
> > axiom is defined.
>
> You talk about an implementation detail (`Blue_extra_super_categories`).
I am
> talking about the fact that in this example (made up) mathematical
axioms do not commute.
Well, yes, the specifications are voluntarily violated by this example
and the infrastructure gives back wrong results (in the form of non
commuting axioms), which is the whole point of the example. Call it
whatever you like, but the infrastructure itself is behaving properly
here: garbage in, garbage out.
I just added the following to the documentation of
Blue_extra_super_categories:
{{{
.. TODO::
Improve the infrastructure to detect and report this
violation of the specifications, if this is
easy. Otherwise, it's not so bad: when defining an axiom A
in a category ``Cs`` the first thing one is supposed to
doctest is that ``Cs().A()`` works. So the problem should
not go unnoticed.
}}}
Cheers,
Nicolas
--
Ticket URL: <http://trac.sagemath.org/ticket/10963#comment:438>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/groups/opt_out.
