#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 SimonKing):
Replying to [comment:431 nthiery]:
> Have you tried the category_sample function?
Now I have, and I get a list of only 97 categories. `Blahs()` is missing.
But anyway, thank you for the pointer.
> Right. But Sage's startup would still require being able to manipulate
> such a Gröbner basis in one form or the other. And one needs to make
> sure the Gröbner basis is consistent with all the code (that is Sage's
> compilation might require a Gröbner basis computation).
In the code, you would provide the local data for the plain acyclic
digraph structure of categories. The Gröbner basis would be used to
extract from it consistent local data of a spanning tree that is specified
by the (fixed) choice of a monomial order. This does not happen at compile
time, but only when a class is created (by a metaclass).
The only difference to the current implementation: Currently, you need to
specify local data for the plain acyclic digraph and ''at the same time''
provide local data for a spanning tree (by moving some stuff into cached
methods rather than class attributes) that is not explicitly specified (it
is implicitly specified by the perceived asymmetry in statements of
mathematical theorems).
I indicated before: Making the database-metaclass-indexed-by-standard-
monomials approach productive clearly is for a different ticket. However,
creating a tool that asserts consistency of the ''current'' implementation
is something that I see happening on ''this'' ticket. That's why I don't
move the discussion to a different ticket, and that's why I keep working
on [attachment:consistency.py].
> Sorry, I can't resist; let me use the very argument that soo many
> people have raised when saying that all that category stuff was just
> overdesign. «Before introducing non trivial design to solve a scaling
> issue, one needs to be sure there is one in practice». So far, I
> haven't had a single time where I got bothered by that.
Well, in my early Sage days I occasionally complained that the source code
of
category stuff can hardly be found (thus, I improved
`sage.misc.sageinspect`) and that
the category framework is responsible for slowing things down (thus, I
made
some contributions in that regard). But I did not raise the very argument
you
are mentioning. So, I am clearly entitled to consider over-design to solve
far-fetched scalability issues `;-)`.
> > > Since every category class is supposed to be TestSuit'ed, we should
> > > cover all categories this way. Do you think we would get a global
> > > enough view?
> >
> > No.
>
> Can you give me a sketch of scenario where this would fail?
I am not saying that it would ''necessarily'' fail. However, a local test
''may'' fail. And rather than repeating the same local test over and over
in the `TestSuite` of any category, I'd like to have ''one'' test
(say, a doctest of `sage.categories.categories_with_axiom`) that takes
into
account the whole digraph and is thus reliable.
> I believe, and will work on proving formally, that the current
> implementation is perfectly well-defined and gives normal forms.
I believe it, too, and I am working on a formal proof (using commutative
algebra), modulo missing instances of some category classes.
In addition, the minimum of what I want is this: Provide a tool that
asserts consistency of choices, so that future developers are prevented
from
doing wrong choices when they extend the category-with-axiom framework.
It would be used as follows: Developer X implements a new category class C
and
wants to make it accessible by applying certain axioms to certain base
categories. Then, X can call a function that returns ''the'' correct
choice of
a default construction, hence, ''the'' correct choice of
`C._base_category_class_and_axiom` (''the'', because it should be uniquely
determined after fixing a monomial order), which also tells where X should
use
a (lazily imported) class attribute and where a cached method in the
`SubcategoryMethods`.
> Anyway, I read you agree that this is all for a later ticket, right?
Partially. A concistency checker is something for here. A database-
metaclass
turning the checker into a productive tool to simplify the implementation
of
new categories-with-axiom is for later.
> Can you please move the discussion to a different ticket?
See reasoning above.
Best regards,
Simon
--
Ticket URL: <http://trac.sagemath.org/ticket/10963#comment:435>
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.
