#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:419 vbraun]:
> IMHO we have to at least get rid of the open-ended list of blessed
adjectives that have special hidden/surprising meaning. This includes all
cases where substrings of class names are matched. We can change the
implementation details later, but whatever programming interface we fix
now will be exceedingly difficult to change once this is merged.
As one of the reviewers, I can tell that Nicolas did seek other people's
opinion, although this has partially happened in off-line discussions.
You are probably aware, but let's make this difference explicit: We have
to
distinguish the ''user interface'' from the ''programming interface''. I
believe the user interface is nice and natural: Take a category ``C``, and
type ``C.Commutative()`` to create a new category obtained from ``C`` by
applying an axiom. I think it makes sense to do it in this way. It would
also
make sense to do it like `C.add_axiom(Axiom.Commutative)`. Anyway, the
current
user interface is sufficiently nice IMHO.
The programming interface is less nice, as we have discussed. When adding
a
new category-with-axiom, the programmer needs to provide a ''default''
construction, which can either be implicit by the choice of a name, or
explicit by providing a "magical" class attribute. This is on the new
category; on the base category, another class attribute needs to be
created,
most likely by a lazy import, or a nested class (which is then the class
for
the new category).
In addition to that, there may be non-default constructions yielding the
same
category. One (minor) problem is that this additional constructions must
not
be defined by class attributes (otherwise the assertions happening in the
code would complain) but by `SubcategoryMethods`.
A major problem is: How to justify the choice of default versus non-
default
constructions? Shouldn't there somehow be a globally consistency? And
should
this concistency not be granted in an automatic way (because otherwise it
isn't granted)?
> Anything else, including the implementation (but not the programming
interface for specifying) relations could be left for later, I agree.
I am not sure if I agree on this statement: Is it really a problem to have
a
handmade non-scalable (because of global consistency) programming
interface
now and then replace it by a more automated scalable programming
interface?
Actually I am more concerned about the implementation of the underlying
lattice. As in the case of coercion, the lattice structure is given
locally,
on the nodes. But some kind of global consistency is required (if you
concatenate coercions, then the result must be a coercion as well, but
there
can be different coercion chains from parent A to parent B, and the
concatenation results must all coincide). Sometimes I find it rather
frustrating that the coercion lattice is encoded in this way, since fixing
a
global problem locally tends to be difficult.
But Gröbner bases of toric ideals are, I think, a tool to treat global
questions locally. What do you think of the following attempt of a
compromise?
- The user interface `C.Commutative` is nice enough, let's keep it as
suggested by Nicolas, for now. In a later stage, if axioms start to get
an
independent life, the syntax `C.add_axiom(axioms.Commutative)` might be
added.
- For practical considerations, I would accept a temporary solution in the
programming interface: As we all know, a lot of patches depend on the
"more
functorial constructions", and I guess it would be easier to change the
way
of defining a default construction later in ''one'' go rather than in
hundred tiny steps (namely by breaking all the existing 100 patches that
depend on the functorial constructions). But I am not release manager,
perhaps I "misunderestimate" the problems.
- ''IF'' we preserve the current programming interface, then we should add
a
tool that allows to compute what ''should'' be the default construction
of a
new category. As I have demonstrated above, this could be provided by
Gröbner basis computations in boolean polynomial rings: Input a category
construction, output the "normal form" of this construction in the
lattice,
which should then be taken as default construction. So, the programmer
can
seek advice before doing a choice what to put into
`_base_category_class_and_axiom` resp. before chosing a name.
- In a ''later'' step, this helper tool to achieve consistency could be
the
fundament of a simpler programmatic interface. The programmer would
state
somewhere in the code (or by calling a method of some object and then
storing an updated database in the Sage sources) that finite division
rings
are commutative, and (perhaps by a database using labels that are
standard
monomials in a boolean polynomial ring) would ensure that in all future
Sage
sessions `Rings.Finite.Division` will coincide with `Fields.Finite`.
--
Ticket URL: <http://trac.sagemath.org/ticket/10963#comment:422>
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.
