#14734: Map from Graphs to Partitions
----------------------------------+-----------------------------------------
Reporter: chrisjamesberg | Owner: sage-combinat
Type: enhancement | Status: closed
Priority: major | Milestone: sage-5.11
Component: combinatorics | Resolution: fixed
Keywords: FindStatDays01 | Work issues:
Report Upstream: N/A | Reviewers: Travis Scrimshaw
Authors: Chris Berg | Merged in: sage-5.11.beta2
Dependencies: | Stopgaps:
----------------------------------+-----------------------------------------
Comment (by ncohen):
Yo !
> I do not agree that the combinatorial_map decorator doesn't have
anything to do with Sage.
My point in this ticket is that this very function has nothing to do in
Sage.
> It organizes mathematical concepts by providing the possibility to ask
for things like:
>
> - which involutions are there on permutations
> - which bijections between 132-avoiding permutations and Dyck paths are
there,
This does not mean that it HAS to be implemented as a decorator. Besides,
right now the decorator seems to replace the function that is decorated by
a new object, which contains the function as a method. This means that
when users that never heard of `find_stat` run Sage commands, some
computations are spent on things that are only needed for your website.
Will you please acknowledge that this is not a good behaviour ? The
discussion will be more interesting if you also acknowledge the problems
that this thing creates.
You can build an index of these functions wherever you want, and this
index will be queried whenever you really need it. You can also add
information to the DOCSTRING of the methods that you find to be of
interest, which will not represent any additional computations for normal
users.
> and so on. The decorator should even be able to carry information about
the maps (though this is not yet there), like "injective", "surjective",
"bijective", ... And these mathematical information are interesting and
useful for Sage users!
Indeed. It would be nice. But the implementation right now is not the good
one.
> Feel free to start a discussion about the decorators on the sage-
combinat mailing list, or to ask for a poll if the community wants such
decorators or not. I will at least copy your comment and my answer there
in order to get a discussion started.
I just wrote an email and sent it to a friend first. The number of people
that cannot both accept to be friend and to think objectively at what they
do makes me unable to talk pleasantly with most people I meet anymore.
> Obviously, the decorator might have downsides. E.g., we have seen that
it not yet works well together with the cached_method decorator.
I hate this decorator too. But there is sometimes a point to it. In
particular, I don't see how it could be immediately improved, while I just
gave you two alternatives above for this decorator.
> I will add some further points once we have a discussion started at
sage-combinat-devel.
I can start it. But on sage-devel. I don't see why the combinat guys
should be the only ones to debate upon Sage's design choices.
Nathann
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/14734#comment:7>
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.
