> That being said we do not want to register all computable maps on
> startup. So we have to find the good balance between interesting maps
> as "the number of descents in a permutation" and uninteresting maps as
> "the polynomial map 57*n^2 - 18*n +3 from {-12, 1, 42, 2243} to the
> integers".
>
>
I don't understand, are you talking about maps or statistics? There are two
different things, unless you consider statistics to be a map from the
object to the integers but I'd say we want to keep two problems separated.
Right now, the combinatorial_map decorator offers already some kind of
semantic information, the fact it flags the methods is in itself semantics.
I agree that there should be more. Right now, you can do:
sage: p = Permutation([1,2,3])
sage: from sage.combinat.combinatorial_map import
combinatorial_maps_in_class
sage: combinatorial_maps_in_class(p)
[Combinatorial map: reverse,
Combinatorial map: complement,
Combinatorial map: permutation poset,
Combinatorial map: Robinson-Schensted insertion tableau,
Combinatorial map: inverse,
Combinatorial map: Robinson-Schensted recording tableau,
Combinatorial map: foata_bijection,
Combinatorial map: descent composition,
Combinatorial map: Increasing tree,
Combinatorial map: Binary search tree (left to right),
Combinatorial map: Robinson-Schensted tableau shape,
Combinatorial map: to alternating sign matrix,
Combinatorial map: Simion-Schmidt map]
The way it works: the decorator replaces the tagged methods by instances of
combinatorial map class, the functions only checks which methods are indeed
instances of this class.
It is partly the information you need even so I'm not sure it's a good way
to have it. And also, this function is hidden somewhere and not accessible
from the object or the parent itself.
About Nathan's suggestion to have a flag, I don't know if it's such a good
idea. The idea is to provide this semantic information to any user of Sage
not machines.
Also, there is no need to bring Findstat into the debate. We have our own
sage branch for the website. Git has made it quite easy for us to maintain
it and do whatever we want in it, the concern here is indeed Sage.
The way I see this, *because* of the FindStat use case, the
combinatorial_map decorator has been introduced and many Sage developers
have been devoted time into adding semantic information into sage methods.
Of course, we could remove this all together, but this would be a great
loss for Sage as this semantic information is useful for users. And Here, I
speak as a combinatorist person working with these objects every day.
So, our concern should be: how to make this information easily available to
users and how could we store this without impacting efficiency of the
program.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
