#10963: More functorial constructions
-------------------------------------+-------------------------------------
Reporter: nthiery | Owner: stumpc5
Type: enhancement | Status: needs_info
Priority: major | Milestone: sage-6.2
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-doc- | Commit:
distributive | 7ab3103368e46d33f37e135a9eb09a1e16a029a7
Dependencies: #11224, #8327, | Stopgaps:
#10193, #12895, #14516, #14722, |
#13589, #14471, #15069, #15094, |
#11688, #13394, #15150, #15506, |
#15757, #15759 |
-------------------------------------+-------------------------------------
Comment (by nthiery):
Replying to [comment:527 vbraun]:
> I disagree, we should definitely not merge this ticket until it is in a
state that does not require any major changes. Anything else will just be
huge pita for anybody trying to learn or use it. Sure we can merge it with
a big fat warning "DO NOT USE THE CODE HERE YET" but then its easier to
just not do it and keep it in a separate git branch. In fact, git makes it
easy to have long-lived branches to work on big features. Nobody is
stopping anyone from working on concrete code...
> In other words, the main goal should not just be to get people moving,
but also have them move in the right direction ;-)
It is *not* a change of direction. The potential changes we are
discussing here are either about the internals, or about a small
syntactical change: basically how the axiom and the base category are
specified. This means that if we decide to change this, there will
just be 2-3 lines of code to change per new category with axiom.
For those already merged in Sage, this is trivial. For the others,
well, developers that are advanced enough to implement new categories
with axiom can handle a warning about a potential change of
syntax. This is all much easier than resolving conflicts, like the one
Simon just found, that will rise as soon as tickets will want to, e.g.
move code to the better spots introduced by the newly available
categories.
Besides, several tickets, like the NSMacdonald one, won't even need
any change; they are just using, or extending, the new categories
provided by this ticket, not creating new ones. And getting them
merged is important: the ns one is (almost) ready and is an important
outcome of our thematic semester at ICERM, and users are waiting for
it. Other tickets represent large contributions of PhD students; they
need to be able to get definitely done with them and get credit for
it.
> In order to make progress, how about you explain what you don't like
> and we'll try to find an approach that makes everyone happy.
I want to have this discussion, but the last two months have proven
that it's unproductive to do it on trac (e.g. a minimum of two hours
of developers time has been spent on the last two comments; what
progress have we actually done?).
This is in good part because there are a couple points for which we
don't have yet enough experience to take well informed decisions; so
it's a lot about belief and intuition, which makes it harder to find a
consensus about. In such a situation, I believe that a decision that
has been battlefield tested for practicality over a non trivial period
on a non trivial body of code is as good as any other and one should
proceed with it.
Anyway, to recap, the main points are:
(1) I believe that, when implementing a category with axiom Cs().A(),
enforcing that the nested class be Cs.A is a feature (it's a
simple rule, it's consistent both with OO practice and with what's
done for other category features, it's explicit enough to specify
which axiom is being implemented, ...)
(3) I don't like having the outer class inspect all its attribute. The
logic better belongs to the inner class.
(4) I believe that adding several axioms at once is not an urgent
feature. Yes, theoretically it looks good at the first sight; but
the balance between the extra amount of logic and the practical
gain is far from clear.
I actually started to steal the implementation from your branch
(creating automatically the necessary intermediate category with
axiom), but without using (2). And then dropped the idea because
it felt like introducing more confusing magic: those intermediate
categories would exist without an explicit class attached to
them. For example, this makes it more complicated to explain where
to add code (it currently reads as: ``if the category with axiom
already exists, put it in the associated class; otherwise create
it'').
(5) I believe that, at this point, modeling the axioms themselves is
overdesign, for we don't actually have a serious use case.
(6) I believe that the performance hit that we get when a category is
repeatedly created over many base rings can be solved in little
time once we can clear our mind from this ticket.
Here are some points on which I'd be willing to change, against my own
intuition, if the reviewers have a strong belief about them:
- A change of syntax for specifying the base category class and axiom
when this information can't be guessed. E.g. using separate
attributes.
- Proceeding with the implementation of (3), but without using (2).
- Simon's as_name change
Best,
Nicolas
--
Ticket URL: <http://trac.sagemath.org/ticket/10963#comment:539>
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.
