#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:419 vbraun]:
> Nicolas, I like you and your contribution but I don't think you
> understood what I'm saying.
I did. The discussion was honestly going out of topic, and I asked
concretely "what else?" had to be done now. Thanks for the second part
of your message elaborating on that question.
> So let me be completely blunt: This
> ticket is nowhere near ready to be merged, and I'm totally opposed
> to giving it positive review at this point. We really should have
> had this discussion before the first line was written. You failed to
> seek any external input when drafting it. There is no post to
> sage-devel about this.
Let's see:
- I have been mentioning this ticket over and over on sage-devel, not
counting sage-combinat-devel. Here is a sample among those:
https://groups.google.com/forum/?fromgroups#!searchin/sage-devel/10963
/sage-devel/1lZAr60N-8w/vHr6nOWrsfcJ
https://groups.google.com/forum/?fromgroups#!searchin/sage-devel/10963
/sage-devel/chC1qH455Qs/NDiN3IOPLBgJ
- I have made presentations about it in at least four Sage days.
- Throughout the whole design process, I have had countless long
e-mail/trac/oral discussions with some of those that care most about
categories, in particular Florent Hivert and Simon King. Simon even
came to Orsay twice in good part to discuss about this.
- The code has been publicly available all time through, with an easy
way to install it, try it, and see non trivial use cases
(sage -combinat install).
- The code has been used by quite a few people.
With that, I believed that everybody interested in the category
infrastructure was aware that non trivial changes were coming. I would
have been happy to expand on the details if anyone had just asked.
Granted: there was no framed official request for comments. Point
taken for next time.
> We even have a formal RFC process (SEP) for foundational changes
> which you did not pursue either.
Where is it formalized? How many time has it been used?
I certainly can see the point of formalizing certain processes. Yet, I
believe that this also has its limits. The point is that, if I had
presented a draft of the current design two-three years ago, the
reactions would have been: "that's just all crazy overdesign", "what's
the point?", or "it can't be made to work reasonably". And that would
have been perfectly fair: I was asking myself the very same question,
and there indeed were some non trivial hurdles to overcome (e.g. the
C3 business).
For such an infrastructure to be convincing, I think it has to be
seriously battlefield tested, for otherwise it only leads to never
ending unsupported-by-facts discussions (I have seen sooo many of
those). The main point is how it feels in practice to write code using
the infrastructure, and in particular how it scales. Not counting: can
Sage start if we actually refactor the internals? are there
performance issues? Can we get to all doctests passing? More than
that: you need (at least *I* need) several iterations of battlefield
testing (three complete rewrites in the case at hand) before
converging to a proper design; at least one that convinces me.
That being said, let's move to the interesting part.
> 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. Its hard
enough to communicate a design paradigm to the wider developer community,
it would be entirely confusing to change it in a year.
>
> Anything else, including the implementation (but not the programming
interface for specifying) relations could be left for later, I agree. But
without having a reasonable idea of what kind of relations we want to
support we can't devise a suitable programming interface. In particular, I
think your current interface of specifying a list of
`extra_super_categories()` is fundamentally flawed for the reasons that I
stated.
Very well. I appreciate your suggestions, but so far none of them
convinced me. Well no, that's not right: I found the idiom
{{{F(axiom.Finite, axiom.Commutative)}} very interesting though it
does not buy the rest. In each case, either I see fine points where
they are likely to be unimplementable within the desired features, or
I believe that they will make category code less nice to write. I'd
be happy to be proven wrong, but it does not make any sense for me
implementing something I don't not believe in a priori. Alternatively,
we can spend a couple days discussing step by step the details.
No, as you have proven repeatedly, in particular with the git
transition, you are a man of action. If you are convinced some change
is right and easy, prove me wrong by implementing a convincing
prototype, say in a review branch. No need to be perfect. I am happy
polishing the details.
As for the ``fundamentally flawed extra_super_categories()
interface''. It's not about relations in an algebra. It's about a
completion computation in a lattice. And in this context I believe
it's correct. Shall I write a formal proof of the algorithm? At least
I would have the feeling to be investing my time for the day I would
write a paper on the topic.
Best,
Nicolas
--
Ticket URL: <http://trac.sagemath.org/ticket/10963#comment:420>
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.
