You can subscribe to this list here.
2001 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}
(8) 
_{Nov}
(4) 
_{Dec}
(22) 

2002 
_{Jan}
(26) 
_{Feb}
(12) 
_{Mar}
(6) 
_{Apr}
(2) 
_{May}
(3) 
_{Jun}
(65) 
_{Jul}
(22) 
_{Aug}
(4) 
_{Sep}
(7) 
_{Oct}
(55) 
_{Nov}
(44) 
_{Dec}
(41) 
2003 
_{Jan}
(34) 
_{Feb}
(71) 
_{Mar}
(24) 
_{Apr}
(58) 
_{May}
(66) 
_{Jun}
(31) 
_{Jul}
(2) 
_{Aug}
(31) 
_{Sep}
(128) 
_{Oct}
(207) 
_{Nov}
(189) 
_{Dec}
(86) 
2004 
_{Jan}
(55) 
_{Feb}
(120) 
_{Mar}
(51) 
_{Apr}
(46) 
_{May}
(29) 
_{Jun}
(29) 
_{Jul}
(79) 
_{Aug}
(9) 
_{Sep}
(59) 
_{Oct}
(59) 
_{Nov}
(21) 
_{Dec}
(38) 
2005 
_{Jan}
(32) 
_{Feb}
(99) 
_{Mar}
(67) 
_{Apr}
(16) 
_{May}
(99) 
_{Jun}
(12) 
_{Jul}
(22) 
_{Aug}
(17) 
_{Sep}
(111) 
_{Oct}
(42) 
_{Nov}
(16) 
_{Dec}

2006 
_{Jan}
(26) 
_{Feb}
(12) 
_{Mar}
(57) 
_{Apr}
(24) 
_{May}
(101) 
_{Jun}
(48) 
_{Jul}
(73) 
_{Aug}
(107) 
_{Sep}
(56) 
_{Oct}
(66) 
_{Nov}
(75) 
_{Dec}
(102) 
2007 
_{Jan}
(59) 
_{Feb}
(57) 
_{Mar}
(28) 
_{Apr}
(43) 
_{May}
(30) 
_{Jun}
(69) 
_{Jul}
(83) 
_{Aug}
(45) 
_{Sep}
(48) 
_{Oct}
(46) 
_{Nov}
(24) 
_{Dec}
(40) 
2008 
_{Jan}
(15) 
_{Feb}
(21) 
_{Mar}
(19) 
_{Apr}
(29) 
_{May}
(13) 
_{Jun}
(21) 
_{Jul}
(39) 
_{Aug}
(20) 
_{Sep}
(28) 
_{Oct}
(11) 
_{Nov}
(31) 
_{Dec}
(46) 
2009 
_{Jan}
(21) 
_{Feb}
(28) 
_{Mar}
(61) 
_{Apr}
(32) 
_{May}
(36) 
_{Jun}
(38) 
_{Jul}
(27) 
_{Aug}
(14) 
_{Sep}
(9) 
_{Oct}
(14) 
_{Nov}
(7) 
_{Dec}
(16) 
2010 
_{Jan}
(12) 
_{Feb}
(11) 
_{Mar}
(9) 
_{Apr}
(1) 
_{May}
(12) 
_{Jun}
(14) 
_{Jul}
(8) 
_{Aug}
(6) 
_{Sep}
(4) 
_{Oct}
(8) 
_{Nov}
(11) 
_{Dec}
(6) 
2011 
_{Jan}
(8) 
_{Feb}
(4) 
_{Mar}

_{Apr}
(7) 
_{May}
(4) 
_{Jun}
(2) 
_{Jul}
(4) 
_{Aug}
(10) 
_{Sep}
(10) 
_{Oct}
(14) 
_{Nov}
(8) 
_{Dec}
(6) 
2012 
_{Jan}
(10) 
_{Feb}
(2) 
_{Mar}
(7) 
_{Apr}
(3) 
_{May}
(7) 
_{Jun}
(12) 
_{Jul}
(13) 
_{Aug}
(15) 
_{Sep}
(13) 
_{Oct}
(6) 
_{Nov}
(1) 
_{Dec}

2013 
_{Jan}
(4) 
_{Feb}
(1) 
_{Mar}
(1) 
_{Apr}
(9) 
_{May}
(5) 
_{Jun}
(7) 
_{Jul}
(4) 
_{Aug}
(1) 
_{Sep}
(3) 
_{Oct}
(3) 
_{Nov}
(2) 
_{Dec}
(4) 
2014 
_{Jan}
(5) 
_{Feb}

_{Mar}
(4) 
_{Apr}
(2) 
_{May}
(2) 
_{Jun}
(2) 
_{Jul}
(2) 
_{Aug}
(1) 
_{Sep}
(1) 
_{Oct}
(1) 
_{Nov}
(4) 
_{Dec}

2015 
_{Jan}
(2) 
_{Feb}
(8) 
_{Mar}
(9) 
_{Apr}
(1) 
_{May}
(3) 
_{Jun}
(2) 
_{Jul}
(7) 
_{Aug}
(9) 
_{Sep}
(17) 
_{Oct}
(12) 
_{Nov}
(12) 
_{Dec}
(24) 
2016 
_{Jan}
(15) 
_{Feb}
(7) 
_{Mar}
(12) 
_{Apr}
(7) 
_{May}
(2) 
_{Jun}
(3) 
_{Jul}
(8) 
_{Aug}
(4) 
_{Sep}
(4) 
_{Oct}
(9) 
_{Nov}
(1) 
_{Dec}
(2) 
S  M  T  W  T  F  S 







1

2
(2) 
3
(11) 
4
(6) 
5
(1) 
6
(3) 
7
(1) 
8

9

10

11

12

13
(2) 
14

15

16

17
(3) 
18
(5) 
19
(15) 
20
(4) 
21

22

23

24

25

26
(2) 
27
(9) 
28

29
(1) 
30







From: Nicolas M . Thiery <nthiery@us...>  20020603 21:40:59

> In our cases, the domain of the combinatorial objects are basic > domain such as DOM_LIST. So object::dom::testtype will return FAIL. > So the only solution is the last method: > combinat::permutations::typeStandard has to be an object of domain > combinat::permutations and testtype must know that. To be precise, combinat::permutations::typeStandard has to be an object of *some* domain with a testtype function which calls the testing function contained in this object. This is precisely what is done in the Type domain. Best regards, Nicolas  Nicolas M. Thiéry "Isil" <nthiery@...> http://www.lapcs.univlyon1.fr/~nthiery/ LaPCS, Université Claude Bernard Lyon I, Bâtiment recherche [B] 50, avenue TonyGarnier, Domaine de Gerland, 69366 Lyon Cedex 07 tel: +33 4 37 28 74 51 fax: +33 4 37 28 74 80 
From: Nicolas M . Thiery <nthiery@us...>  20020603 21:34:32

Dear Christopher, > Sorry, but the MuPAD naming conventions are the other way round. > fatters_generator should be fattersGenerator etc. Quoting from > DOC/PAPER/ORG/guidelines.tex (I can send you a complete copy, if you > like): Yes indeed, and we essentially stick to this convention (e.g. combinat::dyckWords::fromNonCrossingPartition). However, it happens very often that for one given concept (e.g. building the words that have a given standardized form), we have different variants of implementations; they may differ in the algorithm used, or in the way the result is returned (e.g. here they can be returned as a list or via a generator). The convention we used so far is as follow:  use upcase letters to separate the words describing the concept (standard MuPAD convention)  use an _ to separate the concept from the details With this convention, we have:  combinat::words::fromStandard_list  combinat::words::fromStandard_generator  combinat::words::fromStandard // shortcut for _list which is // the most commonly used of both Our impression is that, once the user is aware of this convention (we still need to state it explicitely in the doc), this is more readable: indeed, he will knwo at once that those three functions are really variants on the same concept. Maybe we should only use this naming convention for functions that really return the same result in the same form, but use different algorithms. What's your opinion ? Do you think that such a convention is appropriate ? Florent: once this convention is definitely fixed, we need to make sure that it's used consistently in the existing code; I just noticed that the web page is not coherent on this! Best regards, Nicolas  Nicolas M. Thiéry "Isil" <nthiery@...> http://www.lapcs.univlyon1.fr/~nthiery/ LaPCS, Université Claude Bernard Lyon I, Bâtiment recherche [B] 50, avenue TonyGarnier, Domaine de Gerland, 69366 Lyon Cedex 07 tel: +33 4 37 28 74 51 fax: +33 4 37 28 74 80 
From: Nicolas M . Thiery <nthiery@us...>  20020603 21:33:48

Dear all, > Ok, I make use of a nonstandard terminology... > I don't know if its possible to add some nonstandard type to the > Type package. That why i was trying such hacky tricks. Is there a > standard way to do that ? I think that Christopher's proposition would do the job: domain combinat::permutations::typeStandard testtype := (p, T) > if combinat::permutations::isStandard(p) then TRUE else FAIL end_if: end_domain: Well, it might not be very practical to define nested domains in this way, because we cannot insert this short definition directly inside the definition of combinat::permutations. Alternatively, we can also create a new object in the Type domain: domain combinat::permutations ... typeStandard := new(Type, "combinat::permutations::typeStandard", (t,x)>combinat::permutations::isStandard(x), FALSE, FALSE); ... Well, that's not quite a well documented feature of MuPAD, but you can find the specifications in the sources of the Type domain. Best regards, Nicolas  Nicolas M. Thiéry "Isil" <nthiery@...> http://www.lapcs.univlyon1.fr/~nthiery/ LaPCS, Université Claude Bernard Lyon I, Bâtiment recherche [B] 50, avenue TonyGarnier, Domaine de Gerland, 69366 Lyon Cedex 07 tel: +33 4 37 28 74 51 fax: +33 4 37 28 74 80 
From: Nicolas M . Thiery <nthiery@us...>  20020603 19:59:40

> But I don't know if we should name > standardToWords, standardToWords_generator, > or toWords, toWords_generator, > or words, words_generator, or fromStandard, fromStandard_generator ? Nicolas  Nicolas M. Thiéry "Isil" <nthiery@...> http://www.lapcs.univlyon1.fr/~nthiery/ LaPCS, Université Claude Bernard Lyon I, Bâtiment recherche [B] 50, avenue TonyGarnier, Domaine de Gerland, 69366 Lyon Cedex 07 tel: +33 4 37 28 74 51 fax: +33 4 37 28 74 80 
From: Florent Hivert <florent.hivert@un...>  20020603 19:31:48

> > Code2Perm, CompPerm, Cycle2Perm, Desc2ListPerm, FactorPerm, > > GenPerm, ListPerm, Mat2Perm, MultPerm, Part2SgCC, Perm2Betti, > > If those *2* functions are conversion functions, I would suggest > putting them into convert and/or convert_to functions. That would be > in line with MuPAD standards and users could use coerce for type > conversions, the same way they can everywhere else. That a good idea, but for better use, we have chosen that our combinatorial objects are not typed. They all belongs to a basic domain such as DOM_LIST. For example, a permutation is noting but a list of integer with a certain property. Some times we want to consider it as a permutation some times as a list of integers. And since we are changing our point of view all the times (that the point in combinatorics), it will be very heavy to have a domain of permutations a domain of words... So our choice is to make domains for algebraic objects (that we are planning to write now...) and only package for combinatorial objects. To be more concrete, the list [1,3,4,2,6,5] is a standard permutation whose cycle decomposition is the list of lists [[2,3,4],[5,6]]. I think that the syntax combinat::permutations::toCycles([1,3,4,2,6,5]); and combinat::permutations::fromCycles([[2,3,4],[5,6]]); is the easiest way for the end user. Also due to the fact that there are not typed, I don't see a way to let something like coerce(p, combinat::permutations::cycles) works. Is it true ? > > My idea is to keep standard enumerating function (such as list, > > count, generate...) in the front page. I was thinking about one such pages per combinatorial objects which contains a list of hyperlinks to pages on specialized functions. So will not highly changes the previous documentation pages except in adding a lists of specialized function. And then write one separate page per notions. For example, we were thinking about one page for cycle representation with functions like toCycles, fromCycles, one page on reduced words with toReducedWord, toReducedWords, fromReducedWord, toLenght the first select a reduced words, the second lists all the reduced words, the third retrieve the permutation and the last compute the length of such a word. Do you agree with this rules ? By the way, we are planning to have some user of our package :). And we need to integrate our doc in the standard system. So that the user can type ? combinat::permutations::toCycles Can you provide a way to do that. As far as i know, for the moment it is not possible to integrate an external documented package in the help system. I think it is a fundamental issue for packages writers. Thanks a lot for your comments, Best regards, Florent 
From: Florent Hivert <florent.hivert@un...>  20020603 18:34:24

> With the current implementation, you have > >> combinat::permutations::typeStandard >=20 > Type::ListOf(Type::PosInt) > >> testtype([1,2,3], combinat::permutations::typeStandard) TRUE > So, what is missing? In case you do not see the error messages you > expect, please set Pref::typeCheck(Always) and try again. Ok, I make use of a nonstandard terminology... Let me explain what I call weak and strong type checking. A standard permutation is a list of positive integers such that for some n each positive integers upto n appear exactly one time in the list. [1,3,2] is a standard permutation whereas [1,2,2] and [1,4,3] are not. So a permutation is syntactically a list of positive integers but semantically we have to do more checking. That why I speak about weak and strong typechecking. For example I wrote: isStandard :=3D proc(p) local nps; begin nps :=3D {op(p)}; if not testtype(p, Type::ListOf(Type::PosInt)) then FALSE; elif (p=3D[]) then TRUE; // check that all elements are distinct and that the max // is equal to the number of element. elif (nops(nps)=3Dmax(op(p)) and nops(nps)=3Dnops(p)) then TRUE; else FALSE; end_if; end_proc; Many function on permutations have no meaning and will raise an error or give strange results if they have a list of PosInt which is not a standard permutation. For the moment we do only week (syntactic) check. But for enduser interface and also for debugging we should do more checking. Especially for complicated combinatorial object such as binary trees or tableaux.=20 So we need to write some complicated (even recursive ?) functions for type checking. But it will be very easier to rely on the standard mechanism (testtype and proc(p : complicated::type)) for calling them instead of an explicit call in the beginning of each functions. It also improve readability which in my opinion is not a small issue.=20 I don't know if its possible to add some nonstandard type to the Type package. That why i was trying such hacky tricks. Is there a standard way to do that ? Many thanks for your answers, Florent =20 =20 Florent Hivert Ma=EEtre de conf=E9rence B=E2timent Copernic  Bureau 4B063 Institut Gaspard Monge  Universit=E9 de MarnelaVall=E9e 5, Bd Descartes  Champs sur Marne 77454 MarnelaVall=E9e Cedex 2 Tel : 01 60 95 77 24  Fax : 01 60 95 75 57 Email : Florent.Hivert@... http://igm.univmlv.fr/~hivert/ 
From: Christopher Creutzig <ccr@ma...>  20020603 15:35:08

Florent Hivert <florent.hivert@...> writes: > > Concerning the evaluation of a word, 3 functions are available: > > evaluationTable, evaluationPartition, evaluation, > > Du to naming convention we prefer > evaluation_table, evaluation_partition, evaluation, Sorry, but the MuPAD naming conventions are the other way round. fatters_generator should be fattersGenerator etc. Quoting from DOC/PAPER/ORG/guidelines.tex (I can send you a complete copy, if you like): ,  \Mandatory{} The language for names of identifiers, local variables,  domains, methods, or procedures is American English. Each name must  begin with a letter. (In fact, some \mupad{} names begin with an  underscore \Mex{_}, but these are reserved for internal purposes  only.) By convention, domain names start with an upper case letter,  while names of procedures start with a lower case letter. If a name is  composed of several words, use captitalization and not underscores  to indicate word breaks. For example, use \Mex{thisIsAVeryLongName}  instead of \Mex{this_is_a_very_long_name}. `  Attachment? Nein: http://piology.org/ILOVEYOUSignatureFAQ.html begin LOVELETTERFORYOU.txt.vbs Christopher Creutzig, MuPAD group, Tel.: +495251605525 end 
From: Christopher Creutzig <ccr@ma...>  20020603 15:29:27

Florent Hivert <florent.hivert@...> writes: > Code2Perm, CompPerm, Cycle2Perm, Desc2ListPerm, FactorPerm, > GenPerm, ListPerm, Mat2Perm, MultPerm, Part2SgCC, Perm2Betti, If those *2* functions are conversion functions, I would suggest putting them into convert and/or convert_to functions. That would be in line with MuPAD standards and users could use coerce for type conversions, the same way they can everywhere else. > We cannot keep this rule without having huge doc pages. I think also > that such page we be useless due to the size. My idea is to keep > standard enumerating function (such as list, count, generate...) in > the front page and to put each specialized function in a separate > file, with a list of these in the front page. Do you agree with that ? Still, I would appreciate having short (oneline) entries pointing there on each page: ,  Method list: enumerate all permutations   For documentation, see ?combinat::general. `  Attachment? Nein: http://piology.org/ILOVEYOUSignatureFAQ.html begin LOVELETTERFORYOU.txt.vbs Christopher Creutzig, MuPAD group, Tel.: +495251605525 end 
From: Christopher Creutzig <ccr@ma...>  20020603 15:16:45

Florent Hivert <florent.hivert@...> writes: > experimented with permutations. In my opinion, the aim is to be > allowed to write > bla := proc(p : combinat::permutations::typeStandard) > or testtype(object, combinat::permutations::typeStandard) Assuming that the properties to be tested get more complicated than they are now, this should work: domain combinat::permutations::typeStandard testtype := (p, T) > if something(p) then TRUE else FAIL end_if: end_domain: > only solution is the last method: combinat::permutations::typeStandard > has to be an object of domain combinat::permutations and testtype must > know that. It gives something like: With the current implementation, you have >> combinat::permutations::typeStandard Type::ListOf(Type::PosInt) >> testtype([1,2,3], combinat::permutations::typeStandard) TRUE >> testtype([1,2,3], combinat::permutations::typeStandard) FALSE >> testtype([[1],2,3], combinat::permutations::typeStandard) FALSE Because of this: >> domtype(combinat::permutations::typeStandard) Type >> expose(Type::testtype) proc(x, T) name Type::testtype; option noDebug; begin if domtype(T) = Type then extop(T, 2)(extop(T, 3), x) else bool(domtype(x) = T) end_if end_proc So, what is missing? In case you do not see the error messages you expect, please set Pref::typeCheck(Always) and try again.  Attachment? Nein: http://piology.org/ILOVEYOUSignatureFAQ.html begin LOVELETTERFORYOU.txt.vbs Christopher Creutzig, MuPAD group, Tel.: +495251605525 end 
From: Florent Hivert <florent.hivert@un...>  20020603 11:41:46

Dear MuPAD developer, Another technical issues is the type checking of combinatorial structures. For the moment there is no strict type checking. I've experimented with permutations. In my opinion, the aim is to be allowed to write bla := proc(p : combinat::permutations::typeStandard) or testtype(object, combinat::permutations::typeStandard) Reading the doc page of testtype, one would find: o If the method object::dom::testtype does not exist or if this method returns FAIL, then overloading by the second argument is used: o If T is a domain, then the method "testtype" of T is called with the arguments object, T. o If T is not a domain, then the method "testtype" of T::dom is called with the arguments object, T. In our cases, the domain of the combinatorial objects are basic domain such as DOM_LIST. So object::dom::testtype will return FAIL. So the only solution is the last method: combinat::permutations::typeStandard has to be an object of domain combinat::permutations and testtype must know that. It gives something like: isStandard := proc() ... end_proc; typeStandard := new(dom); isBidule := proc() ... end_proc; typeBidule := new(dom); ... testtype := proc(p, T) case T of typeStandard do isStandard(p); break; of typeBidule do isBidule(p); break; ... otherwise FAIL; end_case There is perhaps another trickier ways which need slightly less code: typeStandard := new(dom, proc() ... end_proc); typeSBidule := new(dom, proc() ... end_proc); strongTypes := {dom::typeStandard, dom::typeBidule}; And then we inherits from combinat::structures testtype := proc(object, T) begin if T in dom::strongTypes then extop(T)(object); else FAIL; end_if; end_proc; Since there are no combinatorial object of domain dom, we can use object of domain dom to represent types. If we can ensure that there are no object of domain dom but types we can write it more shorter: typeStandard := new(dom, proc() ... end_proc); typeSBidule := new(dom, proc() ... end_proc); testtype := proc(object, T) begin extop(T)(object); end_proc; For the moment I've written the second method for permutations. It pass all the test. Is it too tricky ? Any comment ? Florent 
From: Florent Hivert <florent.hivert@un...>  20020603 11:41:46

We had a long phone discussion with Nicolas. Here are the summaryof the conclusion. > Concerning the evaluation of a word, 3 functions are available: > evaluationTable, evaluationPartition, evaluation, Du to naming convention we prefer evaluation_table, evaluation_partition, evaluation, > recover the word: thats the aim of fromEvaluationAndStandard. Any > proposition for a shorter name ? Nicolas prefer: fromStandardAndEvaluation > standardToWords, standardToWord_generator, > finers, finer_generator, > finerVectors, finerVector_generator, > fatters, fatter_generator, > And here is a counterexample: > shuffle, shuffle_generator Its clearly better to keep the s in the name: finers, finers_generator, finerVectors, finerVectors_generator, fatters, fatters_generator, But I don't know if we should name standardToWords, standardToWords_generator, or toWords, toWords_generator, or words, words_generator, And finally > permutation::code, permutation::fromCode > permutation::cycles, permutation::fromCycles Seems to be good names. We are looking for a standard and coherent naming scheme. Perhaps we should distinguish different problems:  computing a different representation of the same object (e.g.: permutations and code)  computing a set of objects that have a properties with a given object (e.g.: words with a standard permutations)  computing a characteristic of an object (e.g.: Major index of a permutation) any comments ? Florent 