Hello guys !
1) I wanted to review #12867, and I then noticed that the function which
returns a "random word of length n on k letters" is so bad that I should be
rewritten rather than fixed.
sage: Words(2, 50).random_element() # Should return a binary sequence of
length 50
I then began to fix i
Okay, this time it did not take long. Quote from the constructor of
Partitions :
if 'parts_in' in kwargs:
return Partitions_parts_in(n, kwargs['parts_in'])
elif 'starting' in kwargs:
return Partitions_starting(n, kwargs['starting'])
Hello everybody !
Because of my previous message on this forum I am now fixing doctests in
the combinat/ folder. I have a problem with the following which appears in
partition.py :
sage: number_of_partitions(10,2)
doctest:1: DeprecationWarning:
sage.combinat.number_of_partitions
, deprecated. Good job.
Nathann
On 29 November 2013 17:17, Nathann Cohen wrote:
> Okay, this time it did not take long. Quote from the constructor of
> Partitions :
>
> if 'parts_in' in kwargs:
> return Partitions_parts_in(n, kwargs['
Y !!
> I think the deprecation message is plain wrong, and it should be
> Partitions(n, length=k).cardinality().
> However, this is nowhere near the speed of the deprecated
> number_of_partitions(n, k)... no idea what happened here!
Well, the 'k' parameter itself has been deprecated f
Hello !
> RestrictedPartions were depreciated in trac5478, incorrectly as you point
> out. See the previous discussion about this point in sage-combinat-devel,
> particularly starting from 30/8//2012. It's listed on trac12278 as an
issue
> to be fixed.
...
Oddly, knowing that it has been known f
Hello !!
>> Oddly, knowing that it has been known for two years that this function
returned wrongs results, and that nobody cared enough to fix it is not
exactly a comforting thought.
>>
> Oddly, given that the sage-combinat discussion referred to above was in
2012, I make it one year
Helloo everybody !
For once I come here to ask something about categories ! There is an
alternative patch for #12867 which is waiting for a review, and modifies
the object "Words(2)", i.e. the set of all (finite or infinite) binary
words.
There was an __iter__ method on that, while th
Yoo !
> RR in Sage *is* countable and *is not* the set of real numbers.
> Nevertheless it is not iterable (I do not know why).
sage: RealField()
Real Field with 53 bits of precision
Oh. Right. Precision.
:-P
> Currently there is only finite versus infinite for sets. I agree with
> you,
Yoo !!
> You can still iterate over *some* elements.
Indeed. My problem with Words(2) is the following :
- If you iterate on it, you just get finite words
- Words(2).random_element() breaks right now, which is fixed in #12867.
There are two patches there, but if you use mine call to ran
>> - If you iterate on it, you just get finite words
Well, first there *IS* a bug there :
sage: Words(3,finite=False)[1]
word: 1
This word is finite while I asked for the set of infinite words. The patch
at #12867 fixes it by refusing to return the first element (no iteration).
So for a start,
> Two fun paradoxes that are in that rabbit hole:
>
> http://en.wikipedia.org/wiki/Bertrand_paradox_(probability)
> http://en.wikipedia.org/wiki/Borel%E2%80%93Kolmogorov_paradox
Hey, I never claimed it was the unique answer. I'm just saying that
anybody who asks Sage for a random binary word word
Helloo everybody !
I got an email from a Sage user who wants to enumerate something, and I'd
need to generate a Gray Code in order to make it faster. And it looks like
Sage cannot do that from my google searches. I would like to list all the
subsets of a Set in a "Gray Ordering". Actually, I w
stha wrote:
>
> You can just hook up the sympy code or use that directly:
> http://docs.sympy.org/dev/modules/combinatorics/graycode.html
>
>
> On 12/05/2013 05:52 AM, Nathann Cohen wrote:
> > Helloo everybody !
> >
> > I got an email from a Sage user who want
Hell everybody !
I am trying to clean Sage of old deprecated code, and found #5457.
This ticket deprecates a function in sage/combinat/sf/kschur.py, and in
particular displays the message :
sage: ks3 = kSchurFunctions(QQ, 3); ks3
doctest:1: DeprecationWarning: Deprecation warning:
>
> perhaps Mike and I can do this.
>
Well, I think one of you is sufficient to deal with this if you know how
the doctests should be replaced. Thanks !
Nathann
--
You received this message because you are subscribed to the Google Groups
"sage-combinat-devel" group.
To unsubscribe from thi
> FYI, this is now #15575.
Cool ! Add me in Cc when it is ready for a review !
Nathann
--
You received this message because you are subscribed to the Google Groups
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-combinat-dev
Hellooo everybody !!!
I send this email because I want to add new stuff to our combinat/designs/
folder, and I really need some help to review patches. These are
constructions of combinatorial designs, i.e. SOoo very sexy set systems.
I don't think such code is available anywhere else. Th
Hello everybody !
This afternoon I read the "Category Primer" [1] and I reviewed #15588.
Which means I know everything there is to know about categories.
If I understood well what Travis taught me in #15588, calling .category()
has no reason to give you the "Smallest category containing y
Yo !
> Note that the upcoming #10963 improves quite some (at least I hope!)
> this primer.
Isn't that a 3yo ticket ? :-P
> Yes. Computed or declared.
Oh, right.
> For C a category, the semantic of ``X in C`` is to test whether X is
> currently known by Sage to be in C, by a declaration or prev
Hell guys !!
Yesterday Simon finished dealing with #15278, which defines equality and
hash methods for immutable graphs. That's a good news for the combinat/
code, as it now uses an ugly hack to pretend that non-immutable graphs are
immutable, and that's a mess. A mess that we will be tryi
Yo !
> I would like to look at huge posets
Would you mind telling me what "huge" means ? It does make a difference
when one writes the code.
> and define a random walk on its
> linear extensions (or eventually run through its linear extensions
> using a Markov chain derived from this one). The m
> > Would you mind telling me what "huge" means ? It does make a difference
when one writes the code.
>
> Probably with hundreds of vertices.
That's huge ? Okay I see. I'm glad I asked. So it's not larger than 65536
:-P
> This was only for you to see what the graphs look like :-)
Well, ...
sage
Y !!
> I certainly can recall dealing with lots and lots of small posets
> (typical for algebraic combinatorics: your combinatorial objects are
> small, but you are often considering all of them at once because you
> are talking formal linear combinations of them and likewise). I also
p
creating this matrix. Hmmm... Wonder what should be done there... O_o
Nathann
On 31 December 2013 11:29, Nathann Cohen wrote:
> Y !!
>
> > I certainly can recall dealing with lots and lots of small posets
> > (typical for algebraic combinatorics: your combina
Hello everybody !
Federico found in #15609 that the following returned nothing :
sage: Derangements(3).rank("Wouhou")
I thought at first that it was a stupid mistake, but it turns out that the
documentation of this rank function explicitly says that None is returned
when the element is not f
Hello !!!
> I'm starting to get interested research-wise in this stuff.
*Great* news (for me) :-PPP
> When trac was reasonably fast, I looked them over and the
formatting/documentation looked fine.
> It seemed like Dima has looked at them as well?
> Now trac is so slow, and since the
Helloo !!
> I did, briefly. I will have some time for this in the 2nd half of
January, after we are back to Oxford.
Well, #15107 has been in needs_review for 4 months and I really wouldn't
mind if somebody reviewed it before the end of the month.
By the way, I think we should use designs
Hello everybody !!
Because of broken doctests in #12867, I find myself opening the file
sage/categories/examples/algebras_with_basis.py, and about to do something
potentially big.
I am about to remplace this
CombinatorialFreeModule.__init__(self, R, Words(alphabet), category =
Algebr
Or possibly : you know that your algebras can break at any moment if you
play with the wrong words, but you want to be able to define this anyway
when you know what you are doing ?...
Nathann
On Sunday, January 5, 2014 3:30:40 PM UTC+1, Nathann Cohen wrote:
>
> Hello eve
Helloo !
> You are right. Infinite words don't belong into an algebra; you cannot
> multiply them. Barring hack reasons, the change is correct.
I love being right for a reason different from the one I had in mind. It's
like I am always right, and natures finds its way around my ignorance
>
> You are right. Infinite words don't belong into an algebra; you cannot
> multiply them. Barring hack reasons, the change is correct.
>
HMmm... And what do you think of Shuffle Algebras on infinite words ? Is
this one correct or not ?
It looks okay to me.. But if you tell me that it is not
Okay, I just created an element manually instead of calling an_element().
Nathann
On 5 January 2014 15:59, Nathann Cohen wrote:
> You are right. Infinite words don't belong into an algebra; you cannot
>> multiply them. Barring hack reasons, the change is correct.
>>
>
H... I just had Nicolas on the phone who told me that both can be
changed to "finite words only". Aand he had Florent around to
confirm.
I also think that the concatenation product is not well defined. And I
actually wrote that in the patch already :-/
On the other hand I did not
> The shuffle algebra is not well defined on infinite words (the product
> becomes an infinite sum). So please turn infinite=False in both
> situations.
Okay... So I will edit #12867 again :-P
Nathann
--
You received this message because you are subscribed to the Google
I just edited ticket #12867. Thank you for your help :-)
Nathann
--
You received this message because you are subscribed to the Google Groups
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-combinat-devel+unsubscr...@googlegr
Hello !
> Ok, done.
Thnks !!!
> I wanted to proceed with #15285, but I don't know how. It seems that I
must first merge #15107 into the develop branch, then merge that thing into
this ticket, to see what this ticket does relative to the other one...
right?
Oh. Well, actually thi
Helloo !
> So it's good to not compute the transitive closure by default, at
> least not for "large posets", and instead have some idiom to state
> "this poset is small enough and I am about to do many comparisons; go
> ahead, compute the transitive closure". Given that the current idiom
>
Yo !
> Thanks so much for your work on improving the internal data structure
> to have faster posets! An immutable graph is certainly much better
> than a matrix over ZZ, at the very least space-wise.
Bon, a propos de ca... En règle générale, je n'aime pas beaucoup qu'on me
félicite ou qu'on me r
Yoo !!
> Perhaps we could just save the information when it really is "for free",
and try to find a new trick to warn the user that he should have been
pre-computing the transitive closure before doing many comparisons.
Hmmm.. I think there is a problem there : the transitive reduction is
> 80% de mon mail était de l'aide technique, et les 20% de remerciements
> ne m'ont pas pris du temps que j'aurais pu consacrer à autre
> chose. Maintenant si tu préfères que je commence mes mails par des
> insultes, je peux aussi!
Je crois que je préfère les insultes, au moins ca fait avancer les
Sorry everybody. I thought these french emails were just exchanged
between us. I didn't mean to send it to the forum. Sorry for that :-/
Nathann
2014/1/9 Nathann Cohen :
>> 80% de mon mail était de l'aide technique, et les 20% de remerciements
>> ne m'ont pas pr
Hello everybody !
Right now with beta4, I get the following when I try to build the doc
of combinat/
---
[combinat ] building [html]: targets for 247 source files that are out of date
[combinat ] updating environment: [config changed] 255 added, 0
changed, 0 removed
[combinat ] Sphinx error:
[com
Sorry, it looks like my local Sphinx had a problem. Removed output/,
build again, and it works.
I love this program. And sorry for the noise :-/
Nathann
--
You received this message because you are subscribed to the Google Groups
"sage-combinat-devel" group.
To unsubscribe from this group and
Graphs are not part of Combinat.
Nathann
On Sunday, January 26, 2014 10:53:49 PM UTC+1, Nicolas M. Thiery wrote:
>
> On Thu, Jan 23, 2014 at 09:55:23AM -0800, Anne Schilling wrote:
> > It is time to update our poster again! The current poster can be found
> at
> >
> >
> http://combinat.sagem
> It would be nice to have (part of)
>
> http://steinertriples.fr/ncohen/tut/LP_examples/
>
> on the poster !!
You think there is a link between LP and Hopf Algebras ? :-P
Nathann
--
You received this message because you are subscribed to the Google Groups
"sage-combinat-devel" group.
To unsub
> This ticket is holding up a bunch of other tickets that depend on it,
> either because they implement themselves new categories with axioms,
> or use features from the ones implemented here. This includes:
This ticket, like every ticket on our trac server, will be merged when the
reviewers w
> sage: P = Parent(category=Cs().Finite())
> sage: P.foo() # ok, nice
> I am a method on finite C's
> sage: P.is_finite() # Where does that come from?
> True
Is this method named 'is_finite' because the axiom's name is "finite"
? If the axiom is "HeyHeyHey" will the ".is_heyheyhey" m
Yoo !
> No, because the Sets.Finite class implements a "is_finite" parent method
> (which always returns True). This happens to be the only parent method that
> finite sets implement, which is why I used it in this example.
Oh, I see. And you would like to have an explicit link between this
C
> Certainly. I am not trying to "vote out a reviewer".
>From your original post:
===
Call for vote
-
[ ] Merge this ticket, and move on with further improvements in follow
up tickets
[ ] This ticket should be held up until everybody is happy
[ ] This ticket does not make any sens
>On that note, I think reviewers shouldn't hold up tickets because they
> don't like the current implementation without providing a working
> alternative and can demonstrate why it's better.
Do you think that a patch should automatically be merged when it has been
waiting for a reviewer for a
wrote:
>
>
> On Tuesday, March 11, 2014 12:40:41 PM UTC-7, Nathann Cohen wrote:
>>
>> >On that note, I think reviewers shouldn't hold up tickets because
>> they
>> > don't like the current implementation without providing a working
>> > alte
Helloo !
> I agree with John. I actually think Nicolas is quite patient trying to answer
> all questions.
You are so kind.
> My suggestion would be either for Volker to implement his alternative on a
> different ticket, so we
> can see it in action and test it, or to let Nicolas' patch go
AHAHAHAHAHAHAHAHAHAAHAHAHAHAHAH.
So let me get this right : the plan to ask the CNRS some money in order to
help you ask the Europe even MORE money, and it is assumed that a
percentage of the bigger grant will go to a guy whose full-time job is to
ask for money ?
If there is something wrong in
Hello everybody !
I am just reporting a bug found on #15978 (which should make digraphs
a bit faster and is otherwise totally unrelated)
sage: Tab = CrystalOfTableaux(['A', 3], shape = [2,1,1])
sage: g=Tab.digraph()
sage: u,v = g.vertices()[:2]
sage: u <= v
...
RuntimeError: maximum recursion dep
Ahem. Of course, the graph there is totally useless :-P
sage: u,v = CrystalOfTableaux(['A', 3], shape = [2,1,1])[:2]
sage: u<=v
Nathann
On Tuesday, April 1, 2014 4:43:20 PM UTC+2, Nathann Cohen wrote:
>
> Hello everybody !
>
> I am just reporting a bug found on
Y !
> It's not related to #14019,
No of course not, but while working on it I tried to make Poset.__eq__
test equality of the two Hasse Diagram.
That was a mistake, for when you test that the Hasse Diagram are equal
1) you test that the vertex set are equal
2) you test that two s
Hello everybody !
I just created a new trac ticket [1] to let us organize the index of all
combinat modules. This thing is a bit hard to read :
http://www.sagemath.org/doc/reference/combinat/index.html
Of course I do not understand half of what all this code does, so I think
the best would be fo
Yo !!
> I created http://trac.sagemath.org/ticket/14582 a while ago with a slightly
> more ambitious goal (and there's a patch on the old combinat queue, which I
> should be port to a branch). However it's fallen to the wayside as math and
> other code has taken priority (and because g
Hello everybody !
I need your help for something that I spent all of today (around six 6
hours) trying to do, and I can't. And I tried. So please, help me.
I am trying to use cartesian products of groups in Sage, and I cannot
implement what I want because of the following problem :
sage: GG = GF
Hello !
> Sorry, I was offline this morning. I just got your message saying you
> had fixed most of the issues in the mean time, but since this might be
> of general interest here is what I had already typed down.
I solved my other group issues, this one has an easy workaround (wrap
everything 10
Oh, sorry, I forgot the bug report : with this branch applied, here is what
happens :
sage: GF(5).cartesian_product(GF(5))((5,5))
Nathann
On 29 April 2014 15:48, Nathann Cohen wrote:
> Hello !
>
>
> > Sorry, I was offline this morning. I just got your message saying you
> &
> I checked it out; at first glance, the issue is that
> element_constructor returns a tuple not an instance of the cartesian
> product. I can commit a fix in an hour or so.
I wrapped it with "self(tuple ...)" before, and it only produced
infinite loops ...
Nathann
--
You received this message
> No surprise, as self(...) calls element_constructor.
The amount of autmatic stuff in this code is so scary that I don't
believe in anything anymore.
At some point I created a function called "a" in a Parent which just
printed a line, called it, and the result was :
1) The line was printed
2) An
> Well, that was a long hour. But it's now on u/nthiery/cartesian_product.
Cool. I am trying to clean the CartesianProduct stuff of additive
groups and it does not look good. The methods are not inherited from
where they should -_-
Right now, my problem is that the __add__ method from a
Combinato
Looks like it works, thanks !
sage: x=GF(5).cartesian_product(GF(5))((1,1))
sage: type(x.value[0])
sage: x.value[0]
1
sage: x.value[0]*5
0
Why did you have to move the code around, though ?
What is the difference between sets.cartesian_product and
categories.cartesian_product ?
Nathann
--
Yo
By the way, do you know what went wrong with my banch ? Yours does not
produce the error, but I have no idea why, nor what was wrong in my
way of doing things... And if I do not want to do the same mistake
again ?...
Nathann
On 29 April 2014 20:22, Nathann Cohen wrote:
> Looks like it wo
Yoo !!
>
> My answer is most likely going to be a bit broad and include stuff you
> already know; I am just taking the occasion to write a blurb that
> could possibly end up somewhere in the documentation (typically as a
> complement of cartesian_product?), if someone finds it useful.
>
Hell everybody !
Here is the problem I met today:
sage: F = FiniteEnumeratedSet(("a","b","c")); F
{'a', 'b', 'c'}
sage: isinstance(F,Parent)
True
sage: F[0]
'a'
sage: F[0].parent()
---
AttributeError
>
> This is one very special case where the Parent/Element relation is
> broken. First of all FiniteEnumeratedSet is not the parent of its
> elements (it is a facade):
>
Well, then I am asking whether it is a good idea / should be allowed.
We already have a tool to store list of elements with
Yo !
> The Sage developer's guide contains the following (yes, it is somewhat
> hidden):
> http://sagemath.org/doc/developer/coding_in_python.html#special-sage-functions
>
> I am sure that opening a ticket on trac to improve the docs is welcomed, for
> example adding the links [1] and [2] in th
> My point was not about the existence of the answer, but the way I
> wrote it :-) Was it helpful?
Oh. As an answer on sage-devel yes, but you can' t write ling things like
that in the doc. I mean, if you do people probably will not find it when
they have the problem.
> This is about the coercion
Yo !
> Yup. We would want to properly support facade FiniteEnumeratedSets
> over plain Python objects and in particular have:
>
> sage: F = FiniteEnumeratedSet(["a","b","c"])
> sage: F("a")
> "a"
>
> However the coercion system currently does not support facades over
> plai
> Well, of course one needs to learn the language and its *context* if one
> wants to program something.
Yes, but we want to make the language easy to work with, and easy to learn.
_add_coerced_elements_ (if it makes any sense, I do not really know what
its ideal name should be) is clearly more in
> Nor mine in the case of coercion and the _..._ methods :-) Because I
> already spent a lot of time on some pieces of the Sage infrastructure
> does not mean I (or anybody on sage-combinat-devel) am responsible for
> all of it. Which is why I suggested to report and make your case on
> sage-devel.
> I think that the rule of thumb ("if you want to implement a magical
> python method __bla__ in Sage, then you should check whether a default
> implementation exists, in which case you usually have to implement
> _bla_, and the documentation of the default __bla__ gives you more
> details what you
> And we shouldn't make (especially *private*) function names too verbose
> just for newbies, not just because they'd get more tedious
> to type, but also because code would get *harder* to read because of its
> length (or width).
1) I have been developping in Python/Sage for the last 4/5 years
> No offense at all.
Oh, none taken at all ! I just wanted to emphasize that working for a
long time with Python and with Sage did not necessarily help.
> I was mainly referring to the __foo__ vs. _foo_ part,
> where (I think) once you've read why they're both there, it's not necessary
> to resta
Hello everybody !
Today I come with this :
sage: sum(Composition([1,2,3]))
...
TypeError: sum() takes exactly 1 argument (0 given)
Some code of mine which uses Composition expected to see 3+2+1=6 there, but
all I got was an exception.
Looks like you are not allowed to change the meaning of .su
Okay, so how should it be fixed ? Darij's ticket is 9 months old.
Nathann
On Monday, May 19, 2014 6:55:51 PM UTC+2, Nicolas M. Thiery wrote:
>
> On Mon, May 19, 2014 at 04:01:52PM +, Simon King wrote:
> > Multiplication? I always think of words as elements of a free group, of
> > course mul
Please help me follow you :
You want to define a + and * operatorsfor Combinations, in such a way that
Combination.sum() is not necessary anymore, which in turn means that
sum(Combination([1,2,3])) would return 6 ?
Nathann
On 20 May 2014 10:16, Simon King wrote:
> Hi Nicolas,
>
> On 2014-05-1
> I would rather deprecate the `.sum()` of Composition.
Which means that the bug I reported will not be fixed before one year ?
> If you want to
> concatenate composition, use `+`.
I do not want to concatenate compositions. I want to sum the integers that
a composition contains. I use compositio
> I have no idea what you are talking about. I was talking about the
> (Python builtin?) function sum(), and I don't think it makes use of
> Combination.sum().
Sorry, I mean "Composition", not "Combination". And
sum(Composition([1,2,3])) does call Composition.sum.
Nathann
--
You received this m
Yo !
> I was mistaken in my previous post. Not sum() is a Python builtin, but
> add(). So, why do you insist on using sum() instead? The following
> works, and according to what you just stated, it is what you want:
What the hell is "add" ? I did not even know this thing existed !
> So, my apolo
Hello !
> Yeah, could be. But (our posts crossed) I guess you want to use add(),
> not sum().
I solved my problem as I usually do : I cast the combinat object to simple
types to avoid these nightmares.
sage: for c in Compositions(4):
: c = map(int,c) # something I can trust
I was just r
> Nathann, seriously: Do you really think that Sage overriding Python's
sum(),
> renaming it as add(), is less confusing than the requirement to implement
> multiplication in a ring by _mul_ rather than __mul__?
What on earth could tie the two together ? sum(Composition([1,2,3])) must
work, period
> In the mean time, we can implement the other approach since it makes
> sense anyway.
Sorry but I lost you again. How can we fix this "sum" problem ? It seems to
have triggered discussions on the additive law among Composition instances.
Nathann
--
You received this message because you are sub
> > That way, the old behavior of sum can still be used through
> > {{{
> > sage: Compositions().sum([Composition([3,2,1]), Composition([1,2])])
> > [3, 2, 1, 1, 2]
> > }}}
>
> +1. Or maybe instead into a multiplicative monoid? I don't have a
> strong opinion either way, but we should take a consis
>
> Just so you know, I intend to "fix" the decorator at some point to reduce
> whatever impact it could have (I learned a bit a more about decorator while
> at PyCon).
>
Our discussion about this is almost 1 year old. If you do not know how to
clean this code this month, please remove it.
Al
Yo !
> I agree, something should have been done a year ago.
Cool !
> But If you think it should be removed and not improved, please do it
yourself.
If think that "If this thing, which was debated one year ago, is not to be
fixed SOON, then we should get rid of it". We are already hosting code
w
> Sorry Nathann, I don't take orders.
No but you should feel responsible for the mess you add to Sage.
> If you want to open tickets, just do so. I don't think a ticket removing the
> map decorator all together would be positively reviewed right now. If you
> really want to know my time frame,
Hello !
> Due to the unfortunate absence of professional programmers to write and
review our code
Come on, that is our job.
> and of mature professional mathematicians to establish clear strategic
decisions for sage, we should actually as a research community be welcoming
of diverse (already-cod
> You asked how you failed me.
Are you *REALLY* answering to that question ? O_o
> Well, I know for a fact that your behaviour on the list has put off
people from contributing to sage.
Gosh. You are.
> Certainly me, and others who could have contributed indirectly to my
research projects. So th
> One use case for statistics which comes to my mind immediately is to
provide
> answers to
Just to make sure : I *NEVER* said that statistics on combinatorial objects
were useless, did I ? My objections are related to the code that is
included in Sage, and how it is written.
>
http://mathoverflo
Hello !!!
> I must say that I'd love to see the findstat search engine as part of sage.
I would love it too. Querying the findstat database from within Sage
is clearly a good thing.
Nathann
--
You received this message because you are subscribed to the Google Groups
"sage-combinat-devel" grou
>
> 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
> integer
> Git has made it quite easy for us to maintain
> it and do whatever we want in it, the concern here is indeed Sage.
Works for me :-P
> 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 i
> Yes I've thought of that.
Yet I was the first to publish ! One year ago ... :-P
https://groups.google.com/d/msg/sage-devel/SnPfidRM9j8/4LbWLMBf-2kJ
> I'm trying to find the best way of doing it. The decorator seems the best way
> to flag. Before returning the orignal function, I could store
> Let's not mix everything here. In FindStat, we do use a database for
> statistics (not maps) but that's not what we're talking about here. We're
> just talking about flagging some object methods as maps with some semantic
> information.
Indeed. You agreed to only talk about the aspects of this d
Yo !
> I find it quite difficult now to follow this thread, I see the answer to
some emails that are not even in the thread...
This is because it was sent to both sage-devel and sage-combinat. After a
while somebody anwers to only one group and mess follows.
> Anyway, I just want to answer to th
1 - 100 of 244 matches
Mail list logo
