[sage-combinat-devel] Re: sage-combinat queue does not apply

[Travis Scrimshaw]

Hey Anne,
   Fixed. For some reason, the review patch for #15311 didn't get deleted 
from the series file, despite the patch file being removed from the queue.

I also disabled Andrew's trac_Kleshchev-partitions-am.patch since it didn't 
apply for me on 5.13.beta0 and we'll be switching to git shortly (as it's 
already ported over).

Best,
Travis


On Tuesday, November 26, 2013 8:13:30 AM UTC-8, Anne Schilling wrote:
>
> Hi! 
>
> A collaborator of mine is trying to install the sage-combinat queue 
> and there seem to be some problems with sage-5.12. 
>
> "Thanks for helping me out. Unfortunately, I closed the terminal where I 
> used the command. It said it was applying some patches and aborted at some 
> point. If I type "sage -combinat status", I see the following: 
>
> Switching to sage combinat root directory: 
> /opt/sage-5.12/devel/sage-combinat 
> Top patch applied: trac_15311-hall_algebras-ts.patch 
> Switching to sage combinat root directory: 
> /opt/sage-5.12/devel/sage-combinat 
> Are all patches applied: False 
> Changed files in the sage-combinat directory: 
> Switching to sage combinat root directory: 
> /opt/sage-5.12/devel/sage-combinat 
>
> Changed files in the sage-combinat patch directory: 
> Switching to sage combinat root directory: 
> /opt/sage-5.12/devel/sage-combinat" 
>
> Probably this means that trac_15311-hall_algebras-ts.patch does not apply. 
> Travis, could you please fix that since it is your patch? 
>
> It is really time to switch to git :-) 
>
> Best, 
>
> Anne 
>

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/groups/opt_out.

[sage-combinat-devel] Re: expanding symmetric rational function products in symmetric polynomials

[Travis Scrimshaw]

Hey Dan,
   This is only a part of the way, but I'd start by doing the computations 
by having t in a polynomial ring R (over QQ say), and the basic variables 
x_i coming from a power series ring over R:

sage: R. = QQ[]
sage: S. = PowerSeriesRing(R)
sage: (1 - t*x1*x3) / (1 - x1*x3)
1 + (-t + 1)*x1*x3 + (-t + 1)*x1^2*x3^2 + (-t + 1)*x1^3*x3^3 + (-t + 
1)*x1^4*x3^4 + (-t + 1)*x1^5*x3^5 + O(x1, x2, x3)^12

Of course there's the reverse too:

sage: R. = PowerSeriesRing(QQ)
sage: S. = R[]
sage: f = (1 - t*x1*x3) / (1 - x1*x3); f
(-x1*x3 - x1^2*x3^2 - x1^3*x3^3 - x1^4*x3^4 - x1^5*x3^5 - x1^6*x3^6 + O(x1, 
x2, x3)^14)*t + 1 + x1*x3 + x1^2*x3^2 + x1^3*x3^3 + x1^4*x3^4 + x1^5*x3^5 + 
O(x1, x2, x3)^12

And if you don't want any grouping:

sage: R. = PowerSeriesRing(QQ)
sage: (1 - t*x1*x3) / (1 - x1*x3)
1 + x1*x3 - x1*x3*t + x1^2*x3^2 - x1^2*x3^2*t + x1^3*x3^3 - x1^3*x3^3*t + 
x1^4*x3^4 - x1^4*x3^4*t + x1^5*x3^5 - x1^5*x3^5*t + O(x1, x2, x3, t)^12

Now to get the HL P polynomials into the correct variables:

sage: Sym = SymmetricFunctions(R)
sage: HLP = Sym.hall_littlewood(t).P()
sage: p21 = HLP[2,1].expand(3)
sage: p21 = p21.substitute(x0=x1, x1=x2, x2=x3)
sage: p21
x1^2*x2 + x1^2*x3 + x1*x2^2 + (-t^2 - t + 2)*x1*x2*x3 + x1*x3^2 + x2^2*x3 + 
x2*x3^2
sage: p21.parent()
Multivariate Power Series Ring in x1, x2, x3 over Univariate Polynomial 
Ring in t over Rational Field

Then from this point you could do some linear algebra using a "nice" 
ordering of the basis:

sage: R. = QQ[]
sage: S. = PowerSeriesRing(R)   # If you aren't getting enough 
terms, add "default_prec=20" to increase the degrees computed
sage: f = (1 - t*x1*x2) / (1 - x1*x2) * (1 - t*x1*x3) / (1 - x1*x3) * (1 - 
t*x2*x3) / (1 - x2*x3)
sage: Sym = SymmetricFunctions(R)
sage: HLP = Sym.hall_littlewood(t).P()
sage: p11 = HLP[1,1].expand(3)
sage: p11 = p11.substitute(x0=x1, x1=x2, x2=x3)
sage: c = f.coefficients()
sage: f[2] - p11 * c[x1*x2]# I only took the degree 2 terms for easier 
viewing/proof of concept
0
sage: f - p11 * c[x1*x2]
1 + (-t + 1)*x1^2*x2^2 + (t^2 - 2*t + 1)*x1^2*x2*x3 + (-t + 1)*x1^2*x3^2 + 
(t^2 - 2*t + 1)*x1*x2^2*x3 + (t^2 - 2*t + 1)*x1*x2*x3^2 + (-t + 
1)*x2^2*x3^2 + (-t + 1)*x1^3*x2^3 + (t^2 - 2*t + 1)*x1^3*x2^2*x3 + ... + 
O(x1, x2, x3)^12

So from this point it would be wrapping this up in a function that iterates 
over partitions in some "nice" way (Sage goes by lex largest to smallest) 
and returns a dictionary of index/value as partition/coefficient, for 
example [1, 1]: -t + 1 (which comes from c[x1*x2]).

Here's the more automated, but less explicit, version:

sage: n = 3   # This could be the input to a function
sage: R. = QQ[]
sage: S = PowerSeriesRing(R, n, 'x', default_prec=n+1)
sage: Sym = SymmetricFunctions(R)
sage: HLP = Sym.hall_littlewood(t).P()
sage: d = S.gens_dict()
sage: make_poly = lambda la: HLP[la].expand(n).substitute(**d)
sage: lead_term = lambda la: prod(S.gen(i)**v for i,v in enumerate(la))

sage: f = prod( (1 - t*S.gen(i)*S.gen(j)) / (1 - S.gen(i)*S.gen(j)) for i 
in range(n) for j in range(i+1,n) )
sage: f
1 + (-t + 1)*x0*x1 + (-t + 1)*x0*x2 + (-t + 1)*x1*x2 + O(x0, x1, x2)^4

sage: ret = {}
sage: for k in range(n+1):# For the default precision
:for la in Partitions(k):
:c = f.coefficients()
:coeff = c.get(lead_term(la), 0)
:if coeff != 0:
: ret[la] = coeff
: f -= coeff * make_poly(la)
:
sage: ret   # This would be the output of that function
{[]: 1, [1, 1]: -t + 1}
sage: f
0 + O(x0, x1, x2)^4

Same code but with n = 5:

sage: ret
{[]: 1, [1, 1]: -t + 1, [1, 1, 1, 1]: t^4 - t^3 - t + 1, [2, 2]: -t + 1}
sage: f
0 + O(x0, x1, x2, x3, x4)^6

Same thing but with n = 8 and the default_prec = 6:

sage: ret
{[]: 1, [1, 1]: -t + 1, [1, 1, 1, 1]: t^4 - t^3 - t + 1, [2, 2]: -t + 1}
sage: f
0 + O(x0, x1, x2, x3, x4, x5, x6, x7)^6

Is this what you were looking for? It's not the fastest (and IDK how it 
would compare to your implementation), but it should work.

Best,
Travis


On Wednesday, December 4, 2013 2:59:08 PM UTC-8, Dan Betea wrote:
>
> Hi there,
>
> Is there a quick way (in Sage) to expand a product like \prod_{i \frac{1-t x_i x_j}{1- x_i x_j} in Hall Littlewood polynomials in the 
> appropriate number of variables? More precisely, given a partition of 
> length <= to the number of variables, I want to compute the coefficient of 
> the corresponding P or Q HL polynomial.
>
> Note this example is known precisely (one of the Littlewood identities for 
> HL polynomials). 
>
> The product I'm interested in is more difficult and contains an extra set 
> of variables y (together with their inverses). It contains univariate 
> factors like \prod_{i} (1-t_0 x_i)(1-t_1 x_i)/(1-t x_i^2) along with "i factors of the above form. Through some magic using Littlewood Richardson 
> coefficients, Kostka polynomials and a deep look into Macdonald, one can 
> obtain the coefficient of P_{\lambda}. However, the process takes a lot of 
> s

Re: [sage-combinat-devel] Re: expanding symmetric rational function products in symmetric polynomials

[Travis Scrimshaw]

Hey Dan,
   Anne's way makes things much more simple/straightforward:

sage: n = 5
sage: R. = QQ[]
sage: S = PowerSeriesRing(R, n, 'x', default_prec=n+1)
sage: Sym = SymmetricFunctions(R)
sage: HLP = Sym.hall_littlewood(t).P()
sage: f = prod( (1 - t*S.gen(i)*S.gen(j)) / (1 - S.gen(i)*S.gen(j)) for i 
in range(5) for j in range(i+1,5) )
sage: HLP(Sym.from_polynomial(f.polynomial()))
HLP[] + (-t+1)*HLP[1, 1] + (t^4-t^3-t+1)*HLP[1, 1, 1, 1] + (-t+1)*HLP[2, 2]

Since it's the coefficient ring, I don't think anything will break when you 
add the additional fraction field variables (if you know these are going to 
be Laurent polynomials, you might want to consider usin the 
LaurentPolynomialRing or the LaurentSeriesRing).

Best,
Travis

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-combinat-devel] Re: expanding symmetric rational function products in symmetric polynomials

[Travis Scrimshaw]

Hey Dan,


> TypeError: unsupported operand parent(s) for '*': 'Fraction Field of 
> Multivariate Laurent Polynomial Ring in y0, y1, y2 over Fraction Field of 
> Univariate Polynomial Ring in t over Rational Field' and 'Multivariate 
> Polynomial Ring in x0, x1, x2 over Multivariate Laurent Polynomial Ring in 
> y0, y1, y2 over Fraction Field of Univariate Polynomial Ring in t over 
> Rational Field'
>
> Something tells me I have to use some LaurentSeriesRing for R (instead of 
> LaurentPolynomialRing) yet R = LaurentPolynomialRing(R1, n, 'y') does not 
> seem to work.
>
>  
   Hmm...it seems multivariate Laurent series haven't been implemented yet. 
>From your error, it should work in the polynomial ring in the x's is over 
the fraction field of the Laurent polynomial ring in the y's. So you could 
try working over the fraction field of polynomial ring in the y's. Another 
possibility would be to remove the negative powers of the y's and use the 
power series rings in the y's over the power series ring in the x's (over 
the polynomial ring in t):

\prod_{ihttp://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/groups/opt_out.

[sage-combinat-devel] A Partitions Pickle

[Travis Scrimshaw]

Hey everyone,
   The following gives a PicklingError:

sage: P = Partitions(5, max_length=4)
sage: loads(dumps(P))

The actual object created in an instance of `IntegerListsLex`, and the 
pickling error is due to the fact that the global options 
`PartitionOptions` cannot pickled since it passes lambda functions as 
parameters. The ParittionOptions cannot be pickled is okay IMO since there 
is a unique such global object in Sage. However, this causes problems when 
creating partitions with constraints (for my purposes, I need all 
partitions of a bounded max length). The solution is to create a new class 
which has class attributes at least for the global options, in fact I'd 
also give it an `Element` as well (and perhaps inherit from `Partitions` -- 
I haven't tried that yet to see if things break):

class Partitions_constraints_new(IntegerListsLex):
Element = Partition
global_options = _Partitions.global_options

   So I have a few questions about this right now. Do we want to still keep 
backwards compatible unpickling of (very) old `Partitions_constraints` 
(below sage-3.4.1), and if so, what should we call this new class? Do we 
want to be able to pass things like NN to `Partitions` (and use this class) 
and/or continue to allow `IntegerListsLex` to vary over a range of n?

   Here's my opinion: I think we should drop the unpickling of these very 
old objects. We should not allow `IntegerListsLex` to range over n, and 
instead use `DisjointEnumeratedSet`. Subsequently we should allow NN to be 
passed to `Partitions` and have that return a `DisjointEnumeratedSet` of 
the respective objects. I'd create the first ticket which fixes the 
pickling error above and replaced `Partitions_constraints` with my proposed 
class above.

Best,
Travis

PS - More bad puns to follow :P

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/groups/opt_out.

[sage-combinat-devel] The queue and Sage 5.13.beta5

[Travis Scrimshaw]

For those who are curious, the queue applies cleanly to 5.13.beta5 and Sage 
starts.

Best,
Travis

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/groups/opt_out.

[sage-combinat-devel] Re: A Partitions Pickle

[Travis Scrimshaw]

Hey Andrew,


> As GlobalOptions are not pickeable I agree that this error probably occurs 
> because of PartitionOptions being passed as an argument to the 
> IntegerListsLex class. Unfortunately, I think that this is the real 
> problem: global options for one class are not intended to be passed as 
> arguments to another class. Global options are meant to deal with only 
> superficial aspects of a class such as how they are printed or latexed. 
> These options should not contain any data which is intrinsic to any 
> instance of the class, so pickling should not depend on them. 
>

   I'm starting to think that we need is a better system for the global 
options. I'm thinking what we could do is change thing around a bit by 
having GlobalOptions inherit from UniqueRepresentation with a __classcall__ 
method that takes no inputs and we subclass that with passing the necessary 
data up via the __init__() method. For example, PartitionOptions would be a 
subclass of GlobalOptions instead of an instance, and it then should pickle 
properly with better separation between different global options.

>
> In the code for IntegerListsLex it appears that the global_options 
> argument to IntegerListsLex may have been added relatively recently because 
> this argument is current *undocumented* and, moreover, it is *not 
> used*anywhere in the class (in other words, we already have at least a 
> documentation bug). 
>

It's necessary for things that subclass IntegerListsLex whose elements use 
a global_option to do their printing, ex. partitions. This was probably 
something we (most likely myself) did on #13605.

>
> I think that adding a global_option argument to IntergerListLex was a 
> mistake and should be reversed. *I would argue that this is self-evident 
> because whenever this feature is used the resulting objects will not 
> pickle.* In particular, this problem is larger than just the example you 
> give above: searching through partition.py reveals several other instances 
> and there may well be other examples in other files. 
>

+1 

>
> I suggest that the correct way out of this pickle is to remove the 
> global_options argument from IntegeListLex and rewrite any code that uses 
> this "feature". Probably the easiest way to do this, given that this 
> happens many times in partition.py, is to make a new class, say 
> PartitionsIntegerListLex, which inherits from IntegerListLex and then 
> overrides any method which uses PartitionOptions.
>
> If you look in my labelled matrix 
> patch you'll see something similar 
> going on, but more in the opposite 
> direction. In this case when a labelled matrix which has rows and/or 
> columns indexed by partitions then options in the matrix are used to pick 
> out the optionable methods of partitions but it does this without changing 
> PartitionOptions. The point is the same, however, in that the global 
> options for one class are local to one class and they should not be relied 
> upon, or passed to, another class.
>
I'll look at it to see if we can get a good solution which works for the 
labelled matrices as well.

> In any case, I feel quite strongly that the global_options argument in 
> IntegerListsLex should be removed and another solution found.
>

+1 as evidenced by the pickling. 

>
> Just in case the general consensus disagrees with me (democracy has its' 
> problems after all:), I'll also give my answers to Travis' other questions.
>
>
>> class Partitions_constraints_new(IntegerListsLex):
>> Element = Partition
>> global_options = _Partitions.global_options
>>
>>So I have a few questions about this right now. Do we want to still 
>> keep backwards compatible unpickling of (very) old `Partitions_constraints` 
>> (below sage-3.4.1), and if so, what should we call this new class? Do we 
>> want to be able to pass things like NN to `Partitions` (and use this class) 
>> and/or continue to allow `IntegerListsLex` to vary over a range of n?
>>
>
> Currently we can pass NN to Partitions or, equivalently None. I think it 
> makes sense as it returns the class of all Partitions which is sometimes 
> useful. I don't know anything about IntegerListsLex, so I can't comment 
> there, but I would like to keep NN as a possible argument to Partitions.
>

Partitions(NN) does return the class of all partitions currently, but if 
you specify any additional arguments such as "max_length", it currently 
gets angry and throws errors.

>
> Regarding old pickles I have nothing against removing them, although I 
> suspect that if you ask this question on sage-dev then you might meet with 
> some resistance. In any case, it is not necessary to remove them: you can 
> simply rewrite __getstate__ and __setstate__ so that they use a version 
> number (no version number defaults to the old version). By doing this it 
> should be possible to have both the old and new pickles happily living side 
> by side on the self. This way, even 

Re: [sage-combinat-devel] Re: The queue and Sage 5.13.beta5

[Travis Scrimshaw]

Hey Jean-Baptiste,
   I've marked #15150 as merged, so it should (hopefully) apply now.

Best,
Travis

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/groups/opt_out.

[sage-combinat-devel] Re: Bug in Core

[Travis Scrimshaw]

Hey Christian,

On Monday, December 16, 2013 2:24:05 AM UTC-8, Christian Stump wrote:
>
> Hi,
>
> do you consider the following a bug?
>
> sage: A = Core([2],4)
> sage: B = Core([2],5)
> sage: hash(A) == hash(B)
> True
>
>  
I wouldn't necessarily call that a bug, as it is necessary since A == B.

The hash of a core only 
>
depends on the list and not on the core. Since the same list considered as 
> an x- and as a y-core are fundamentally different objects, I would rather 
> suggest to have the hash depending not only on the list.
>
> Let me ask this, is being a k-core a property of a partition or is it a 
*distinct* combinatorial object?

I think of it as a property since we look at partitions and classify them 
as being k-cores, and because of that, I think they should evaluate as 
equal. Moreover, the 4-core [2] is also a 5-core, so I think this is 
correct:

sage: Core([2],4) in Cores(5,2)
True

Since the cores are elements, the "A is B" should be False. However if we 
do agree that these are not equal, we should print that these are k-cores; 
something like "[2] as a 4-core".

Here's also a similar situation, suppose you have a 5-bounded partition 
[2], should it evaluate as equal to the 4-bounded partition [2], or the 
usual partition [2] in Partitions() (or Partitions(2))? They all have 
different parents, so should they not evaluate as equal and/or have the 
same hash?

For the record, the core() method is actually about a different type of 
core (see the method's doc).

Best,
Travis

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-combinat-devel] Re: Bug in Core

[Travis Scrimshaw]

> The reason why we need(ed) a separate core class is that for example 
> otherwise 
> it would not be possible or easy to implement the action of the affine 
> symmetric group 
> on (k+1)-cores. 
>
> Of course, one can ask whether a given partition is an n-core and that 
> method 
> should live in Partitions, but the moment there are operations that only 
> make 
> sense on the set of n-cores, it seems necessary to implement a separate 
> class. 
>

I agree, although I'd prefer it to be a subclass. However this can be 
somewhat tricky (see beow).

>
> In fact, since Travis brought up the issue about a possible class for 
> k-bounded 
> partitions. I have some currently private code on some new methods on 
> k-bounded partitions that I think make most sense inside a class of 
> k-bounded 
> partitions, but of course I could also put them straight into Partitions. 
> What should I do? 
>
>
   I'd want this to be a subclass since it looks like a partition and 
quacks like a partition, but it can also do tricks using its different 
colored feathers. However the problem then becomes when we apply an 
operation as a partition, we might leave the k-bounded world, so we need to 
change our return type. The natural thing (IMO) to do at this point would 
be to return the class and parent which fits our object in general, unless 
we want to do checks everytime we call this object. On the other hand, we 
have methods which always return our special type when starting from our 
special type (ex. take the transpose of a k-core), so do we convert the 
object after calling the general method or re-implement the method?
   One way to get around these things is to have the class be completely 
separate and have conversion functions when needed, which is what's 
currently done for cores. This has the added benefit of having the user 
explicitly do the conversions, so there are less surprises, but this 
separates us from what it is specializing. IDK, at the end of the day (and 
this long-winded response), I think subclass is best since it links the 
objects and it is a partition (at least in the case of k-bounded 
partitions) that just satisfies additional constraints which allows it 
extra methods.

Also one can think of the k in k-core as an extra argument to the methods 
such as to_bounded_partition().

Best,
Travis

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/groups/opt_out.

[sage-combinat-devel] Re: Speed regression in KirillovReshetikhinTableaux?

[Travis Scrimshaw]

Hey Volker,
   I'm working on it. It's likely not a speed regression per-say, but 
instead doing more checks in one of tests (specifically it seems to be 
`_test_stembridge_local_axioms()`) due the implementation being more 
mathematically correctly. I'll post a fix which will clean this up today.

Best,
Travis


On Tuesday, December 24, 2013 6:38:13 AM UTC-8, Volker Braun wrote:
>
> E.g. timing on the "sextus" bulidslave (note that nothing happening in 
> 1200 sec leads to buildbot timeout):
>
> buildbot@sextus$ ./sage -t --long src/sage/combinat/rigged_configurations/
> Running doctests with ID 2013-12-24-08-26-25-aafe2102.
> Doctesting 19 files.
> sage -t --long src/sage/combinat/rigged_configurations/__init__.py
> [0 tests, 0.00 s]
> sage -t --long src/sage/combinat/rigged_configurations/all.py
> [0 tests, 0.00 s]
> sage -t --long 
> src/sage/combinat/rigged_configurations/bij_abstract_class.py
> [54 tests, 0.65 s]
> sage -t --long src/sage/combinat/rigged_configurations/bij_type_A.py
> [19 tests, 0.59 s]
> sage -t --long src/sage/combinat/rigged_configurations/bij_type_D.py
> [75 tests, 0.60 s]
> sage -t --long src/sage/combinat/rigged_configurations/bijection.py
> [6 tests, 0.48 s]
> sage -t --long src/sage/combinat/rigged_configurations/kleber_tree.py
> [203 tests, 23.03 s]
> sage -t --long src/sage/combinat/rigged_configurations/kr_tableaux.py
> [207 tests, 1211.20 s]
> sage -t --long 
> src/sage/combinat/rigged_configurations/rigged_configuration_element.py
> [104 tests, 2.13 s]
> sage -t --long 
> src/sage/combinat/rigged_configurations/rigged_configurations.py
> [208 tests, 1318.53 s]
> sage -t --long src/sage/combinat/rigged_configurations/rigged_partition.py
> [54 tests, 0.91 s]
> sage -t --long 
> src/sage/combinat/rigged_configurations/tensor_product_kr_tableaux.py
> [91 tests, 296.24 s]
> sage -t --long 
> src/sage/combinat/rigged_configurations/tensor_product_kr_tableaux_element.py
> [64 tests, 1.55 s]
> sage -t --long src/sage/combinat/rigged_configurations/bij_type_A2_dual.py
> [19 tests, 0.59 s]
> sage -t --long src/sage/combinat/rigged_configurations/bij_type_A2_even.py
> [19 tests, 0.63 s]
> sage -t --long src/sage/combinat/rigged_configurations/bij_type_A2_odd.py
> [19 tests, 0.66 s]
> sage -t --long src/sage/combinat/rigged_configurations/bij_type_B.py
> [34 tests, 0.83 s]
> sage -t --long src/sage/combinat/rigged_configurations/bij_type_C.py
> [28 tests, 0.62 s]
> sage -t --long 
> src/sage/combinat/rigged_configurations/bij_type_D_twisted.py
> [25 tests, 0.63 s]
> --
> All tests passed!
> --
> Total time for all tests: 2864.5 seconds
> cpu time: 2145.8 seconds
> cumulative wall time: 2859.9 seconds
>

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/groups/opt_out.

[sage-combinat-devel] Re: Speed regression in KirillovReshetikhinTableaux?

[Travis Scrimshaw]

This is now http://trac.sagemath.org/ticket/15581.

Best,
Travis

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/groups/opt_out.

[sage-combinat-devel] Re: combinat and sage 6.0

[Travis Scrimshaw]

Hey Martin,
   Do you know what features and/or patches in particular you're after? I 
can start a public/combinat branch with those.

Side note, I've created http://trac.sagemath.org/ticket/15628 for what we 
decide to do with the combinat scripts.

Best,
Travis


On Saturday, December 28, 2013 6:48:34 AM UTC-8, Martin R wrote:
>
> Hi there!
>
> I just downloaded a sage 6.0 binary (because I'm thinking of reviewing a 
> ticket :-), and did sage -combinat install, and this stops with
>
> /home/martin/sage-6.0-x86_64-Linux/sage -clone combinat
> sage-run received unknown option: -clone 
>
> (I did install git, in case that matters.  I admit however, I didn't 
> follow the git discussions so far.)
>
> I then read http://wiki.sagemath.org/TentativeConventions (I should have 
> done this first)
>
> So, there are two questions:
>
> * I guess sage -combinat is obsolete, right?
> * how do I access the patches from the combinat queue now?
>
> Many thanks,
>
> Martin
>

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/groups/opt_out.

[sage-combinat-devel] Re: Russian

[Travis Scrimshaw]

Hey William,
   I don't know Russian, but hopefully this will clarify some of the terms.


>  - Combinatorics: "tableau" - I'm wondering if I should translate it 
> generically as 'table' (which is a term in Russian combinatorics) or 
> is it something more specific - maybe if you gave more of a 
> description I could figure it out. 
>

I remember hearing the term "table" as a synonym (translation?) for 
"tableau".

>
>  - Combinatorics: "word" - is that a special term or does it literally 
> mean 'word'? 
>

A word is a collection of letters (variables) in an alphabet, so IMO it 
literally means "word".

>
>  - Combinatorics: "root system" - IDK. Which area of combinatorics is 
> it related to? 
>

Lie theory and Coxeter groups. I'd guess this is mentioned in Dynkin's 
papers?

>
>  - Combinatorics: "crystals" - I'm assuming this literally means 
> 'crystals' and is related to physical structures. 
>

As I understand it, not exactly. I believe this was a term coined by 
Kashiwara which models the temperature of particle systems at absolute zero 
(it comes from representations of quantum groups). Perhaps there would be 
something in Reshetikhin's papers about a Russian term for this?

Anna, thank you for doing the translation.

Best,
Travis

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/groups/opt_out.

[sage-combinat-devel] Re: Input for skew tableaux

[Travis Scrimshaw]

Hey Christian,
   I'm split on checking data, on one hand, it's good for the obvious 
reasons, however I don't like the performance hit it can have when creating 
many such elements. Here, I think `to_word()` should work with the 0's (or 
any filling which we can make an alphabet for that matter). Although I've 
never been to fond of the `check` argument that's used in things like 
Permutation, but if we wanted to check input, we should have the option to 
not check as either check (entries or shape) is O(n).

Best,
Travis


On Friday, February 7, 2014 5:33:05 AM UTC-8, Christian Stump wrote:
>
> Hi,
>
> Is it on purpose / can I rely on the following behaviour for skew tableaux:
>
> sage: tab = 
> SkewTableau([[0,1,None],[None,None,1,2],[None,None,0,0,1],[1,None]]); tab
> [[0, 1, None], [None, None, 1, 2], [None, None, 0, 0, 1], [1, None]]
>
> As we also had for compositions, it appears that I can even give other 
> stuff into a skew tableau. Anyway, because of the 0's, methods like 
> "to_word" are broken, and because of the not very shapy shape, "shape", 
> "inner_shape", and "outer_shape" are also broken.
>
> I actually thought that such a multi purpose skew tableau might be nice to 
> implement Le diagrams, but I guess that this is too much of a hack relying 
> on bad behaviour of skew tableaux...
>
> Is it worth opening a ticket for input tests of skew tableau then?
>
> Cheers, Christian
>

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-combinat-devel] tensor products of free modules; combinatorial algebras

[Travis Scrimshaw]

Hey Mark,

I believe the standard way to setting the prefix is to use the "prefix" 
optional argument when constructing / initializing a CFM.

>
> Is there a way to hijack this capability for input mangling or coercion 
> for the custom subclass? I would like to say something like 
>
> sage: C([a,b]) 
>
> and receive the element 
>
> a \otimes b 
>
> of C, where C is an instance of the custom class A \otimes B, 
> a is an element of A and b is an element of B. 
>

You can override the _element_constructor_(self, x): to perform a 
*conversion* on the list, something like:

if isinstance(x, (list, tuple)):
return self.monomial(self._basis_keys(x)) # it's probably overkill to 
explicitly convert it to an element of the indexing set here


> At any rate, what is the way to construct or specify elements for the 
> tensor product, 
> aside from this special constructor "tensor"? 
>

Given a tensor square S of a CFM T, we can construct elements by 
S.monomial( (f1, f2) ) where f1 and f2 are elements of the original 
indexing set (basis keys) of T. Similarly S.sum_of_monomials, S.term, and 
S.sum_of_terms all work. This can be extended to k tensor factors by taking 
tuples of length k. For examples, see implementations of coproduct_on_basis 
(e.g. in qsym.py).

>
> It is wrong to coerce from the standard tensor product of algebras 
> as this would not be an algebra morphism. 


> Is there a way to tell the coercion mechanism that the map is only 
> a module morphism and not an algebra map, even when both objects 
> are algebras? 
>

Yes, *coercions* should preserve the structure (i.e. here it should be an 
algebra morphism). However we can specify *conversions* which can be much 
weaker than coercions. So if you're (thinking of) doing something like 
register_as_coercion(), all you would have to change is 
register_as_conversion() or just implement something in the corresponding 
_element_constructor_(). If I remember correctly, there's an example of 
this in the NCSym code...

Best,
Travis

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-combinat-devel] tensor products of free modules; combinatorial algebras

[Travis Scrimshaw]

Hey Mark,
   I would say so. Although at that time I was focused just on piecing 
together the coercions, it probably should be abstracted so we can do 
something like:

sage: tensor([phi, psi, xi])

given some module morphisms phi, psi, and xi to get a morphism of the 
appropriate tensor products. Is this suppose to be a part of #1? I 
won't be doing finite tensor products in #15726 if that's what you're 
thinking of Nicolas.

Best,
Travis

On Monday, February 17, 2014 11:09:25 AM UTC-8, Mark Shimozono wrote:
>
> Nicolas, 
>
> It is #15305 which is merged. 
> However the morphism-tensoring code seems to be embedded in some code for 
> coercions, rather than abstracted into its own method and used in the 
> coercion. I even saw in the log that you requested this. 
>
> Travis, am I interpreting things correctly? 
>
> --Mark 
>
> > Luckily it's been implemented in a recent ticket, though I don't 
> > remember which one nor its status. 
> > 
> > Cheers, 
> > Nicolas 
> > -- 
> > Nicolas M. Thiéry "Isil" > 
> > http://Nicolas.Thiery.name/ 
> > 
> > -- 
> > 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...@googlegroups.com . 
>
> > To post to this group, send email to 
> > sage-comb...@googlegroups.com. 
>
> > Visit this group at http://groups.google.com/group/sage-combinat-devel. 
> > For more options, visit https://groups.google.com/groups/opt_out. 
> > 
> > 
>
>
>
>
>
>

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/groups/opt_out.

[sage-combinat-devel] Re: Misleading documentation about Cartan types

[Travis Scrimshaw]

Hey Dan,
   I was referring to how the arrows correspond to the matrix values. 
However I can see the potential confusion and take blame for it. I agree 
that we should clarify this.

Best,
Travis


On Tuesday, February 18, 2014 3:56:21 PM UTC-8, bump wrote:
>
> In the Cartan type documentation (cartan_type.py) we find the following 
> statement:
>
> The direction of the arrows is the **opposite** (i.e. the 
> transpose)
> 
>
> of Bourbaki's convention, but agrees with 
> Kac's.
>   
>   
>
>   
>   
> 
>
> For example, in type `C_2`, we 
> have::
>   
>  
>
>   
>   
> 
>
> sage: C2 = DynkinDiagram(['C',2]); 
> C2
>   
>  
>
> 
> O=<=O 
>   
> 
>
> 1   
> 2 
>   
> 
>
> 
> C2
>   
> 
>
> sage: 
> C2.cartan_matrix()
>   
>   
>
> [ 2 
> -2]   
>   
> 
>
> [-1  
> 2]
>   
>
>
>   
> This appears in the reference manual on this page:
>
>
> http://www.sagemath.org/doc/reference/combinat/sage/combinat/root_system/cartan_type.html
>
> It is correct that Bourbaki's Cartan matrix is the transpose of Kac. 
> However both have
> the same convention regarding Dynkin diagrams: the arrow points from the 
> long root
> to the short.
>
> I think we should correct this.
>

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/groups/opt_out.

[sage-combinat-devel] Re: Misleading documentation about Cartan types

[Travis Scrimshaw]

Hey Dan,

Another question: Sage automatically warps CartanType(['A', n, 2]) to 
> CartanType(['BC',n/2,2]) 
> when n is even. This differs from Kac' notation. Whose notation is this?
>

Just as a side note, if you want to display this in Kac's notation, you can 
use:

sage: CartanType.global_options(notation='Kac')
sage: CartanType(['A',6,2])
['A', 6, 2]

Best,
Travis

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-combinat-devel] Further affine matters

[Travis Scrimshaw]

Hey Dan and Nicolas,

On Thursday, February 20, 2014 4:43:37 AM UTC-8, Nicolas M. Thiery wrote:
>
> Hi Dan! 
>
> On Wed, Feb 19, 2014 at 03:34:53PM -0800, bump wrote: 
> >Is the invariant inner product implemented already in the ambient 
> space? 
> >I think what is called inner product is actually the dual pairing 
> >between the space and its dual. This is defined in ambient_space.py. 
>
> The point of the inner product defined in ambient_space is that it 
> provides both the dual pairing, if we apply it to a pair of elements 
> from both sides (e.g. a coroot and a root) and the invariant inner 
> product if we apply it to a pair of elements of the same size (e.g. a 
> root with another root). 
>
> Of course it gets a bit trickier in the affine case (for the inner 
> products between c, \delta, \delta^check, ...); but I believe the 
> current inner product is likely to be what you want. See the 
> documentation of AffineSpace in type_affine for details, try it, and 
> report! 
>
> In http://trac.sagemath.org/ticket/15384 (which is still somewhat 
sketchwork code), I implemented a method symmetric_form() for the root 
space. This should (hopefully) work for the roots, but I am doubtful that 
it works for pairing the fundamental weights. I haven't really attempted to 
really push the code yet. Here at the end of my ramblings, I don't think 
anyone has implemented what you want.

Personally I don't like doing things in the ambient space. Well...it's 
mainly for type A, since (3,2,1) should equal (2,1,0), but these give 
different inner products using the usual Euclidean form.

Best,
Travis

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/groups/opt_out.

[sage-combinat-devel] Re: Installation of sage-combinat

[Travis Scrimshaw]

Hey Norha,
   You can do one of two things:

1 - Download a pre-compiled source from 
http://www-ftp.lip6.fr/pub/math/sagemath/linux/index.html, and then extract 
it. Once that's done, you should be able to simple go into the new 
directory and run Sage.
2 - Go into the directory where you've extracted the source code (this is 
the Sage directory and is likely called path/to/something/sage-6.1.1/ and 
that path/to/something is likely the directory where you extracted the 
tarball), read the README.txt, in particular the "Quick Instructions to 
Build From Source" and "More Detailed Instructions to Build From Source" 
sections, and then follow the appropriate instructions. They basically say 
to just run "make" in the directory with the README.txt and come back in a 
few hours.

As for Sage-Combinat specifically, I don't believe we have a branch which 
contains all/most of the combinat branches... Nicolas, Anne, ...?

Best,
Travis


On Friday, February 21, 2014 1:47:29 AM UTC-8, nohra hage wrote:
>
> Good-morning,
>
> I have Linux ubunto on my PC and i want to install Sage-combinat.
> thanks to http://www-ftp.lip6.fr/pub/math/sagemath/src/index.html, i can 
> install the folder 
> *sage-6.1.1.tar.gz*and
>  after i decompressed it. but i don't khow how to complete the 
> installation.(I read that i have  to write /make in sage directory but i 
> don't khow where is Sage directory)
>
>
> Thank you for your helps,
>
> Nohra Hage
>
>

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-combinat-devel] tensor products of free modules; combinatorial algebras

[Travis Scrimshaw]

Hey Mark,
   It's probably that some of the internal code relied on a spkg being 
upgraded, which isn't done when running `sage -b`. So now you should be 
okay with just using `sage -b`...

Best,
Travis


On Monday, February 24, 2014 6:07:40 PM UTC-8, Mark Shimozono wrote:
>
> Well, 
>
> I tried doing 
>
> make start 
>
> After that, the code worked!  Somehow 
>
> sage -b 
>
> was not properly remaking sage.  I have no idea why not. 
>
> --Mark 
>
> > Terribly sorry for all the spamming but I'm truly perplexed by the 
> > following error.  I tried a similar toy example to test the **keywords 
> > syntax and it worked. 
> > 
> > I thought I had changed the 
> sage.categories.modules_with_basis.ModulesWithBasis 
> > tensor ParentMethod to accept keyword arguments. 
> > 
> > sage/categories/modules_with_basis.py 
> > 
> > class ModulesWithBasis(Category_over_base_ring): 
> > class ParentMethods: 
> > def tensor(*parents, **keywords): 
> > 
> > - 
> > 
> > I did sage -b and then ran a test where I tried out the new syntax and 
> > got the following error. 
> > 
> > [mshimo@shimozono categories]$ sage -t modules_with_basis.py 
> > Running doctests with ID 2014-02-24-10-24-02-32d69c8c. 
> > Doctesting 1 file. 
> > sage -t modules_with_basis.py 
> > ** 
> > File "modules_with_basis.py", line 456, in 
> sage.categories.modules_with_basis.ModulesWithBasis.ParentMethods.tensor 
> > Failed example: 
> > M = A.tensor(A, A, category = ModulesWithBasis(QQ)) 
> > Exception raised: 
> > Traceback (most recent call last): 
> >   File 
> "/home/mshimo/sage-git/local/lib/python2.7/site-packages/sage/doctest/forker.py",
>  
> line 480, in _run 
> > self.execute(example, compiled, test.globs) 
> >   File 
> "/home/mshimo/sage-git/local/lib/python2.7/site-packages/sage/doctest/forker.py",
>  
> line 839, in execute 
> > exec compiled in globs 
> >   File " sage.categories.modules_with_basis.ModulesWithBasis.ParentMethods.tensor[5]>",
>  
> line 1, in  
> > M = A.tensor(A, A, category = ModulesWithBasis(QQ)) 
> > TypeError: tensor() got an unexpected keyword argument 'category' 
> > 
> > -- 
> > 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...@googlegroups.com . 
>
> > To post to this group, send email to 
> > sage-comb...@googlegroups.com. 
>
> > Visit this group at http://groups.google.com/group/sage-combinat-devel. 
> > For more options, visit https://groups.google.com/groups/opt_out. 
> > 
> > 
>   
>   
>   
>   
>
>

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/groups/opt_out.

[sage-combinat-devel] Re: git question

[Travis Scrimshaw]

Hey Mark,
   AFAIK, you'll need to manually merge in the base (lower) branch into the 
dependent (upper) branch (although only when you need the changes in the 
base branch) and push the appropriate branch to the server when changes are 
made. If there's any changes that were not pulled in from the base branch 
to the dependent branch when both are merged, git will take care of it.

Best,
Travis


On Thursday, February 27, 2014 10:21:18 AM UTC-8, Mark Shimozono wrote:
>
> Can someone please explain the proper way to maintain a pair of local 
> branches, one dependent on the other, 
> all the while keeping both branches synchronized with the server? Assume 
> that the
> lower branch is fairly stable but might need to be updated a few times, 
> while the upper branch is
> in rapid flux.
>
> Your explanation can then get added to the sage-git primer; at least it 
> wasn't clear to me how to
> solve the above problem using the existing explanations.
>
>

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-combinat-devel] Re: git question

[Travis Scrimshaw]

I'm not quite sure...perhaps try running "sage -sync-build" because maybe 
it's using a file that is no longer there?

On Thursday, February 27, 2014 12:59:03 PM UTC-8, Mark Shimozono wrote:
>
> Thanks. 
>
> I'm having the recurring problem of first changing filename.py, 
> then running 
>
> sage -b 
>
> and then when I again run 
>
> sage -t filename.py 
>
> the error message reflects the old code. 
> Any ideas on what is going wrong? 
>
> --Mark 
>
> >AFAIK, you'll need to manually merge in the base (lower) branch into 
> the 
> > dependent (upper) branch (although only when you need the changes in the 
> > base branch) and push the appropriate branch to the server when changes 
> are 
> > made. If there's any changes that were not pulled in from the base 
> branch 
> > to the dependent branch when both are merged, git will take care of it. 
> > 
> > Best, 
> > Travis 
> > 
> > 
> > On Thursday, February 27, 2014 10:21:18 AM UTC-8, Mark Shimozono wrote: 
> > > 
> > > Can someone please explain the proper way to maintain a pair of local 
> > > branches, one dependent on the other, 
> > > all the while keeping both branches synchronized with the server? 
> Assume 
> > > that the 
> > > lower branch is fairly stable but might need to be updated a few 
> times, 
> > > while the upper branch is 
> > > in rapid flux. 
> > > 
> > > Your explanation can then get added to the sage-git primer; at least 
> it 
> > > wasn't clear to me how to 
> > > solve the above problem using the existing explanations. 
> > > 
> > > 
> > 
> > -- 
> > 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...@googlegroups.com . 
>
> > To post to this group, send email to 
> > sage-comb...@googlegroups.com. 
>
> > Visit this group at http://groups.google.com/group/sage-combinat-devel. 
> > For more options, visit https://groups.google.com/groups/opt_out. 
>   
>   
>   
>   
>
>

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-combinat-devel] Re: git question

[Travis Scrimshaw]

Hey Mark,
   Try running "make build" in your Sage root. I believe the most recent 
changes require you to update your spkg's (which sage -b does not do). 
Although I recall that this takes awhile due to some ATLAS changes.

Best,
Travis

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/groups/opt_out.

[sage-combinat-devel] Re: expanding in symmetric functions (revisited)

[Travis Scrimshaw]

Hey Dan,
   The reason why you're getting the symbolic ring error is because you are 
saying the matrix should have coeff in SR (the symbolic ring) but the 
matrix coeff you've specified are in the power series ring. So it should 
work if you change SR to S in the M = matrix(...) line (I suspect this is a 
typo). IMO one thing that will make it easier to code/read:

sage: R1 = FractionField(QQ['t'])
sage: t = R1.gen(0) # and use t

and instead of doing S.base_ring().gen(...), use R.gen(...) since 
S.base_ring() is R.

Pfaffians are in sage:

sage: M = matrix([[0,2],[-2,0]])
sage: M.pfaffian()
2

A side question from me, should we have a function/method for computing 
Vandermonde's?

Best,
Travis

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/groups/opt_out.

[sage-combinat-devel] Re: Tensors on free modules of finite rank

[Travis Scrimshaw]

Although at some point we do need to unify CombinatorialFreeModule with the 
other sage (sparse) modules. However I am opposed to a category for free 
modules since they are the same object. Instead I would put common 
functionality into a common base class which implements a generic coercion 
map between its various subclasses.

Best,
Travis

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-combinat-devel] Re: Call for vote about ticket #10963: axioms and more functorial constructions

[Travis Scrimshaw]

Hey everyone,
   I've been using #10963 in developing #14901 (Lie algebras). I first gave 
'Lie' as an axiom of NonAssociativeNonUnitalAlgebras (which I just asked 
Nicolas for how to do it without really looking at the examples), but 
decided that I didn't want _mul_() to give the Lie bracket, so I just made 
the category LieAlgebras be a subcategory of Modules. Next I implemented 
two axiom subcategories of WithBasis and FiniteDimensional (on my own) and 
I felt that it was natural and straightforward. This was about half a year 
ago (before much of the documentation was written).

   Now I feel that Volker's suggestion of making axioms into objects is a 
somewhat heavy-handed approach to something which is basically to act as a 
property, close to decorator interfaces in Java but here axiom determine 
inheritance. So I'd think a list/tuple of strings specifying what axioms 
are implemented is a better way to do it if we don't want to use Nicolas' 
implementation (which I don't object to).

   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. This is what follow-up 
tickets are for; because if it's such a big issue, then people *will* work 
on it. Our development model is somewhat fast, however I've been told that 
Facebook pushes changes to it's live server after possibly only a quick 
check (I've see FB change radically from one day to the next because of 
this). So I will officially vote and say let's merge this ticket in as we 
can always revisit this.

Best,
Travis

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-combinat-devel] Re: [sage-devel] Re: Call for vote about ticket #10963: axioms and more functorial constructions

[Travis Scrimshaw]

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
> > 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 long time ?
>

That's not close to what I said. 

>
> From time to time, I think that what a ticket implement is not a good 
> idea. I usually say so on the ticket and refuse to review it (i.e. #13624).
>

This is a bad practice. Some implementation is better than none, and doing 
things your way turns people off from reviewing the tickets.

>
> I still think that implementing the reviewer's remarks is the author's 
> job, though. Otherwise you will end up with careless reviews, because the 
> reviewers have no time to improve somebody else's code. And I wouldn't want 
> to see careless patches either, written assuming that the reviewer will fix 
> the problems.
>

I'm not disagreeing with you when there are errors and specific comments. 
Yet when the reviewer refuses to let something into Sage because (s)he 
thinks there is a better way without demonstration slows and sometimes 
halts progress. Otherwise we should stop improving computers because 
there's a better way to make them, so let's figure that out first before 
doing anything more. There are so many examples in history of things we 
should have done differently, but we only found out by doing the "wrong" 
thing first. BTW, that is one slipperly slope of logic jumps.

Best,
Travis

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-combinat-devel] Re: How about a class method for R_tilde polynomials in class "KazhdanLusztigPolynomial"

[Travis Scrimshaw]

Hey Aalen,
   Welcome to Sage. I think this will be a useful addition, so go ahead an 
open a ticket. Also, if you find yourself writing functions like this (that 
aren't a part of sage but are doing it often), you can put it in a .sage 
file and then run

sage: %attach path/to/file/name.sage

which will load it into Sage.

Best,
Travis


On Thursday, March 13, 2014 4:37:31 AM UTC-7, Aalen Guo wrote:
>
> Hi, I'm a newbie in sage. 
>
> Everytime I wanna have the R_tilde polynomials I have to write a function 
> to convert from R-polynomials.
>
> So I think a "KazhdanLusztigPolynomial" with R_tilde Polynomial method 
> will be good, what do you think? Should I open a ticket? (actually I just 
> have my trac account a few days ago).
>
> ps: When I say R_tilde polynomials I mean the polynomial connected to the 
> R-polynomials via the following relation:
> R_{u,v}(q)=q^{l(u,v)/2}\tilde(R)(q^(1/2)+q^(-1/2)).
>
>
> Dyer, M. (1993). Hecke algebras and shellings of Bruhat intervals. 
> Compositio Mathematica, 1, 91–115.
>

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-combinat-devel] Re: Infinite loop when comparing two crystal elements

[Travis Scrimshaw]

It's not related to #14019, but a problem with <= comparison in the tensor 
product of crystals code. I inadvertently ended up fixing this with #15882 
trying to get full coverage to combinat/crystals/tensor_product.py:

sage: u,v = crystals.Tableaux(['A',2], shape=[2,1])[:2]
sage: u,v
([[1, 1], [2]], [[1, 2], [2]])
sage: u <= v
True
sage: v <= u
False

So let's finish #15882. Nathann, could you do a review of its dependency 
#14275?

Best,
Travis


On Tuesday, April 1, 2014 8:25:29 AM UTC-7, Nathann Cohen wrote:
>
> 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 #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 depth exceeded in cmp 
>>
>> Looks like the same kind of stuff that happened when I was working on 
>> #14019. 
>>
>> 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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-combinat-devel] Re: Organize the index of combinatorial modules

[Travis Scrimshaw]

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 getting the doc to cross-link is 
a pain). So this could be a good first step towards what I had in mind for 
#14582.

Best,
Travis


On Friday, April 4, 2014 3:08:25 AM UTC-7, Nathann Cohen wrote:
>
> 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 for everybody to checkout this ticket and have a look, 
> and sort his own stuff. I grouped a bit of things into categories already, 
> you may [like/not like] it... Well, do come on the ticket and change what 
> you like. The purpose is to give newcomers some clear idea of what can be 
> found in the combinat code.
>
> Have fn !
>
> Nathann
>
> [1] http://trac.sagemath.org/ticket/16058
>

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Re: Organize the index of combinatorial modules

[Travis Scrimshaw]

As soon as I'm able to I will.

Best,
Travis

On Friday, April 4, 2014 8:02:21 AM UTC-7, Nathann Cohen wrote:
>
> 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 getting the doc to cross-link 
> is 
> > a pain). So this could be a good first step towards what I had in mind 
> for 
> > #14582. 
>
> Ahahahah. I was sure that something had been created about that 
> already. Okay, so #16058 will be a first step toward #14582. Can you 
> group more elements from the current "unsorted" category ? 
>
> 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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] tensor products of free modules; combinatorial algebras

[Travis Scrimshaw]

Hey Nicolas and Mark,
   Somewhat of a side remark: I think we should also have the 0 module 
accessible as a special object in the category of modules (since it is the 
terminal object and we might take tensor products). Actually, perhaps we 
should have that object as a class which we can add in for isomorphic 
objects (along with a method for constructing some instance of that class)? 
For example, suppose I go

sage: C = CombinatorialFreeModule(QQ, [])

then C would inherit from a class, say TermialObject which has special 
coercion properties and when tensored with another module M returns M back.

Best,
Travis

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] tensor products of free modules; combinatorial algebras

[Travis Scrimshaw]

Hey Mark,

Ack...my bad. If we were to have a separate category for tensor products of 
modules, then I agree that it should not be in there to avoid 
technical/implementation issues.

Best,
Travis


On Sunday, April 6, 2014 1:31:20 PM UTC-7, Mark Shimozono wrote:
>
> Travis, 
>
> The zero module is not in the tensor category; its tensor product with 
> anything else is 0. 
> But it is the identity object for direct sums. 
> I could see it being very helpful if, for example, one was implementing 
> some formal 
> Grothendieck group that didn't have a really convenient basis. 
>
> --Mark 
>

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-combinat-devel] Re: fractional powers of a variable

[Travis Scrimshaw]

Hey Mark,
   The workaround Andrew and I used in the Iwahori-Hecke algebra was to use 
a new variable v and passed in q=v^2. Although this led to a minor panic 
when I couldn't get the output to line up with references (everything was 
squared).

Best,
Travis


On Tuesday, April 15, 2014 10:19:25 AM UTC-7, Mark Shimozono wrote:
>
> Nicolas,
>
> I find myself in legitimate need of fractional powers of a variable q,
> which sage  doesn't seem to like.
>
> Is there a reasonable workaround?
>
> I thought about always raising to an extra power (the maximum denominator 
> is
> known) but I don't know how to mangle the output to put the fraction back 
> in.
> I assume it is dangerous to mess with _repr_ for a polynomial
> and the code is assuming that the user is allowed to specify their own ring
> with a q in it.
>
> --Mark
>
>

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-combinat-devel] Re: CombinatorialFreeModule

[Travis Scrimshaw]

The indexing set for CombinatorialFreeModule should be a parent, not an 
element. So

C = CombinatorialFreeModule(QQ, Foos())

and you should have your Foo initialize itself as an element (which will 
fix that tab completion error; I've encountered it when not initializating 
the category for an element):

class Foo(Element):
def __init__(self, parent, a):
self.data = a
Element.__init__(self, parent)

Another smaller example is src/algebras/hall_algebra.py.

Best,
Travis


On Friday, May 16, 2014 10:24:03 AM UTC-7, Bruce wrote:
>
>
> Thanks to all who have responded. My template now looks like:
>
> class Foo(Element):
>
> def __init__(self,a):
> self.data = a
>
> def __repr__(self):
> return str(self.data)
>
> class Foos(Parent, UniqueRepresentation):
> # This class represents the set of all Foo's
> def __contains__(self,f):
> return isinstance(f,Foo)
>
> Element = Foo
>
> FreeM = CombinatorialFreeModule(QQ,Foo)
>
> One problem is that 
>
> s = Foo(1)
>
> and then trying to inspect using s.Tab gives
>
> AttributeError: 'NoneType' object has no attribute 'category'
>
> and FreeM(s) gives
>
> TypeError: No conversion defined from None to Free module generated by 
>  over Rational Field
>
> However FreeM.monomial(s) does work
>
>
>
>
>
>

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Re: sum(Composition([1,2,3])) # broken

[Travis Scrimshaw]

I think we would have to implement __mul__() as Composition does not 
inherit from MonoidElement, nor is Compositions in the category of Monoids. 
So there is no implementation of __mul__() inherited by the element_class 
(which goes into the coercion framework).

Best,
Travis

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-combinat-devel] Re: redesign combinatorial statistics

[Travis Scrimshaw]

Okay here's where I think we are, and my 2 cents in the matter.

Simon wants to have a database which stores the map information which is 
constructed by the decorator @combinatorial_map in order to not have it 
cause any slowdowns. The question is, "how to do this?"

Here's my 2 cents of a solution. The first time the object is called when 
we want to get the map info, have it iterate over all it's methods and call 
any method wrapped in @combinatorial_map. The decorator then does:

def combinatorial_map(f):
# Check if the object's class and the method's name is in the database;
#   this might not be the right python
if (f.self.__class__, f.__name__) in DATABASE:
DATABASE.add(...)
return f

This has the advantage of being dynamic, so it shouldn't hamper startup 
time, and only occurs the first time the object is created, so repeated 
uses won't be slow. We could also go one small step further and have an 
(cython) ABC which does this behavior on initialization.

Best,
Travis

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-combinat-devel] Re: Extednding tableaux

[Travis Scrimshaw]

Hey Andrew,
   Darij was wanting to do this, but if I remember correctly, he is going 
to be busy the next few weeks and there was 
http://trac.sagemath.org/ticket/15862 on mutating tableaux that needed to 
be addressed.

Best,
Travis


On Thursday, July 10, 2014 7:11:52 AM UTC-7, Andrew wrote:
>
> I have this vague memory that some one was thinking of 
> extending/rationalising/reorganising the tableaux code so that it fitted 
> together better (whatever this might mean:). Does this ring any bells with 
> anyone?
>
> I ask because I think that I need to implement row standard tableaux 
> (possibly of composition shape).
>
> Andrew
>

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-combinat-devel] Re: quiver algebra

[Travis Scrimshaw]

Hey Nicolas,
   I would say this is like matrices: do you want the iterator for matrices 
to iterate by default over all elements or rows? Currently the iterator 
goes over all rows and you can call M.list() to get a flat list of entries.

   Actually, this is a question for graded objects in general: should the 
default iterator go over each graded component or all elements? I would say 
there should be methods for both. My thought is the default iterator being 
over graded components since each component might be infinite, but I don't 
have a good/strong opinion/reason for this.

Best,
Travis


On Friday, July 11, 2014 7:24:25 AM UTC-7, Nicolas M. Thiery wrote:
>
> Hi path algebra fans! 
>
> I am having doctests failures in #8678 because of the following 
> "feature" of quiver path algebras: 
>
> sage: P = DiGraph({1:{2:['a']}, 2:{3:['b']}}).path_semigroup() 
> sage: A = P.algebra(GF(7)) 
> sage: A.list() 
> [Free module spanned by [e_1, e_2, e_3] over Finite Field of size 
> 7, 
>  Free module spanned by [a, b] over Finite Field of size 7, 
>  Free module spanned by [a*b] over Finite Field of size 7] 
>
> And indeed ``A.__iter__`` states that it iterates over the homogeneous 
> components of A. This sounds bad, since the general convention for 
> parents is to have __iter__, list, ... iterate over its elements.  And 
> indeed some code that makes this assumption explodes. 
>
> Can we just rename this feature? Is it actually useful? 
>
> Cheers, 
> Nicolas 
> -- 
> Nicolas M. Thiéry "Isil" > 
> http://Nicolas.Thiery.name/ 
>

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-combinat-devel] Re: weyl group element of E8 act on a positive root to get some partiular root but the below program shows error

[Travis Scrimshaw]

As I understand it, the error is because GAP ran out of memory (because the 
Weyl group is too big for your computer's memory basically).

Best,
Travis

On Monday, August 18, 2014 9:15:27 AM UTC-7, Biswajit Ransingh wrote:
>
> W=WeylGroup(['E',8])
>
> R = RootSystem(['E',8]).root_lattice()
>
> alpha = R.simple_roots();alpha
>
> [w for w in W if w.action(alpha[1])==(alpha[1]+alpha[2])]
>
> Output shows : gap: cannot extend the workspace any more!
>

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-combinat-devel] Re: Making code for some seminormal representations faster

[Travis Scrimshaw]

Hey Andrew,
   I'm always for including things into Sage. We need to refactor symmetric 
group representations to not use CombinatorialClass (and the seminormal 
form for the SGA), and we can factor out common functionality at that 
point. However that's for later.

   Now looking at what you're doing (somewhat quickly), since you're going 
to take a fraction field at the end, I would work over ZZ['q'] rather than 
the Laurent polynomial ring since the usual polynomial rings over ZZ 
typically behave better for reduction in the fraction fields. Also are you 
doing any division with the roots? If not, I think you can just work with 
the fraction field of ZZ['q'] and then work with the extension of that. If 
you are, then perhaps consider refining the category of the final extension 
using ``_refine_category_`` to a domain (field?). Unfortunately I don't 
know of a way to add all roots of a polynomial simultaneously, perhaps ask 
on sage-devel.

Best,
Travis

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Making code for some seminormal representations faster

[Travis Scrimshaw]

``_rmul_`` and ``_lmul_`` (it's the module element (i.e., ``self``) on the 
right or left respectively), and (somewhat unfortunately) I think you need 
to also inherit from ModuleElement (or copy the ``__mul__`` method).

Or is it preferred to use ``_acted_upon_`` (see in CombinatorialFreeModule)?

Best,
Travis


On Thursday, November 6, 2014 1:04:30 AM UTC-8, Andrew wrote:
>
> Dear Bruce and Travis,
>
> Thanks for your suggestions. I realised after reading your posts that a 
> much better way to construct my coefficient ring is to start with a 
> polynomial ring over Q(q) with n+1 indeterminants  and then quotient out by 
> a suitable ideal. This constructs the ring directly and the factorisation 
> properties that I wanted are now automatic:
>
> sage: SeminormalRepresentation([2,2]).tau_character(1,2)
> 1/q*I*r3
>
>
> Just a short answer for now: it's been in the TODO list for a while to 
>> have representation matrices for the Hecke algebra (there might be a 
>> ticket about this, and almost certainly a note in the road map). So 
>> progress in this direction is surely welcome, especially if this can 
>> be done uniformly for symmetric groups versus hecke algebras and type 
>> A versus generic type. 
>>
>
> Yes, you're right, this is almost certainly on the roadmap. In any case, 
> as Nicolas and Travis are both in favour I'll try and make time to properly 
> wrap and prettify the code, create a ticket and push it to git and trac or 
> comments and review. I'll first have to think a little harder about the 
> best interface.I will probably end up implementing the seminormal 
> representations simultaneously for the symmetric groups and, more 
> generally, he Hecke algebras of type A, B, ..., G(r,1,n) as in the end thee 
> are all the same.
>
>
>> By the way, this could be an occasion to make those methods of the 
>> symmetric group / hecke algebra. Something like: 
>>
>> sage: SymmetricGroup(5).representation([3,2], "seminormal") 
>>
>>
> Yes this is a good idea, but now there are some questions.
>
>1. Left modules or right modules, or both? (My current methods you can 
>interpret as either.)
>2. What is the best syntax for the action?
>
> The first question is not a big deal. For the second the following is 
> probably the most natural answer::
> sage: A=SymmetricGroupAlgebra(QQ,3)
> sage: rep=SeminormalRepresentation([2,1])
> sage: a=A.an_element(); a
> 2*[1, 2, 3] + 2*[1, 3, 2] + 3*[2, 1, 3]
> sage: r=rep.an_element(); r
> 2*f(1,2/3) + 2*f(1,3/2)
> sage: a*r  # left action
> ???
>
>
> Using a*r for the left action, and r*a for the right action, seems to be 
> the natural syntax. Is there already a mechanism in place for doing this? I 
> assume that there is, but I don't know it. Can some one point me in the 
> right direction?
> Andrew
>

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Making code for some seminormal representations faster

[Travis Scrimshaw]

> On Friday, 7 November 2014 03:56:16 UTC+11, Nicolas M. Thiery wrote:
>
>>
>> This might be the occasion to add a ``cartan type'' for G(r,1,n). 
>>
>
> Implementing these algebras properly would be painful...however, 
> implementing their action on a representation in terms of the natural 
> generators is not, which I guess is what you are suggesting.
>

   I've come across a similar situation with quantum group representations 
(where implementing the actual algebra is difficult compared to 
implementing the representations and the action of natural generators). 
What I ended up decided was best was have methods corresponding to each 
type of generator, and so if/when the algebra is implemented, the action 
would call the corresponding method. I'm very open to a discussion about 
this.

>
> I have realised that attaching the seminormal representations to the Hecke 
> algebras creates a few additional headaches that are associated with the 
> choice of base ring and the choice of parameters of the Iwahori-Hecke 
> algebra. For example, the seminormal representations are naturally defined 
> over Q(q), but the Hecke algebra defined over Z[q,q^-1] also acts on them 
> since this algebra embeds in the algebra over Q(q). Technically, however, 
> the seminormal representation is not a representation for the Hecke algebra 
> defined over Z[q,q^-1].
>
> The question here is whether we should follow the strict mathematical 
> definitions and only allow the Hecke algebras with exactly the same base 
> ring to act or should we be more flexible?  The former is easier in terms 
> of coding whereas the latter is more useful.
>

   I think it depends on how you implement the action; where you could 
perhaps just do the action of a term generator by generator and then 
convert the coefficient into Q(q) and scale the result. Although (I 
believe) the coercion framework would naturally do a pushout construction 
of the Hecke algera over Q(q) and then do the action. I guess what I'm 
saying if you try to make this very mathematically strict, you will likely 
have a fight with the coercion system and it will be different than many 
other parts of Sage.

>
> Then there are other annoyances in that the seminormal representations for 
> the algebras with different quadratic relations, for example 
> $(T_r-q)(T_r+1)=0$, $(T_r-q)(T_r+q^{-1})=0$ or $(T_r-q)(T_r+v)=0$, are all 
> different and, of course, there are several different flavours of 
> seminormal representations. Any suggestions on what we should try and 
> support here would be appreciated.
>

   The biggest thing (to me) is any convention choices that are made are 
well-documented. What about the relations used for the 
IwahoriHeckeAlgebra_nonstandard or some other "idiosyncratic (but 
convenient)" relations?

>
> Another thought that occurs to me, which I don't promise to follow through 
> on, is that I could use the seminormal representation to define Specht 
> modules for these algebras over an arbitrary ring. It is possible to do 
> this using some specialisation tricks. I am not sure how efficient this 
> would be but I suspect that it would be at least as good as my 
> implementation of the Murphy basis in chevie 
>  that I wrote 
> for the Hecke algebras of type A. 
>
> In thinking about this it seems to me that currently there is no framework 
> in sage for dealing with module that has more than one "natural" basis. Is 
> this right? Of course, it is possible to define several different 
> CombinatoriaFreeModules and coercions between them.
>

As Anne said, combinat/descent_algebra.py, or the Iwahori-Hecke algebras. 
What you want to look (grep) for is "WithRealizations".
 

> A final question: where should this code go? Currently the Iwahori-Hecke 
> algebras are defined in sage.algebras and the seminormal matrix 
> representations in sage.combinat. I think the best place might be to put 
> all of this code in a new directory sage.algebras.iwahoriheckeagebras/
>
>I agree with Anne that iwahori_hecke_algebras is a better name for the 
subfolder as I can actually read that without getting cross-eyed. :P 
However I would say it depends on how many new files (python modules) you 
think you'll create. If it's only one or two, I think you can just put it 
in the algebras folder.

Best,
Travis

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-combinat-devel] Re: Left and right cells of Coxeter groups

[Travis Scrimshaw]

Hey Andrew,

Am I right in thinking that sage does not (yet) know about the left, right 
> and two-sided Kazhdan-Lusztig cells of Coxeter groups? As sage can compute 
> Kazhdan-Lusztig polynomials I assumed that it knew about cells as well, but 
> it doesn't seem to. Please tell me if I am missing something.
>

AFAIK, there's no code in Sage or ticket about cells. +1 to adding them.

>
> Incidentally, I also noticed that we have some identity issues -- that I 
> am sure are well known:
>
> sage: WeylGroup("A5")
> Weyl Group of type ['A', 5] (as a matrix group acting on the ambient space
> )
> sage: CoxeterGroup("A5")
> Coxeter group over Universal Cyclotomic Field with Coxeter matrix:
> [1 3 2 2 2]
> [3 1 3 2 2]
> [2 3 1 3 2]
> [2 2 3 1 3]
> [2 2 2 3 1]
>
> I am guessing that one of these is just wrapping code from chevie, but I 
> haven't checked. Is there any reason not to amalgamate these two classes? 
> Currently the CoxeterGroup code seems marginally faster but perhaps the 
> WeylGroup classes have more functionality:
>

   I implemented the current CoxeterGroup and it uses Sage's (hence gap's) 
matrix group code. However the WeylGroup does have more information 
(features) since it is considered acting on the root/weight lattice, such 
as reflection_to_root on elements. Combining these classes might be taken 
care of by http://trac.sagemath.org/ticket/15703.

>
> sage: WeylGroup("A5").cardinality()
> 720
> sage: CoxeterGroup("A5").cardinality()
> ---
> NotImplementedError   Traceback (most recent call last
> )
>  in ()
> > 1 CoxeterGroup("A5").cardinality()
>
> /usr/local/src/sage/local/lib/python2.7/site-packages/sage/categories/
> sets_cat.pyc in cardinality(self)
>1370 NotImplementedError: unknown cardinality
>1371 """
> -> 1372 raise NotImplementedError("unknown cardinality")
>1373
>1374 # Functorial constructions
>
> NotImplementedError: unknown cardinality
>
> There's currently http://trac.sagemath.org/ticket/16630 which should fix 
some (all?) of these issues (and I will get to that after next week).

Best,
Travis

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-combinat-devel] Re: Left and right cells of Coxeter groups

[Travis Scrimshaw]

Hey Andrew,
   It may not be the best name, but if you pass 
implementation="permutation", then it will go to the chevie implementation. 
This isn't explicitly mentioned in the doc (and probably should be), but 
the doctests testing this are marked as optional needing chevie. So I think 
what you need is already there.

Best,
Travis


On Sunday, November 9, 2014 9:11:48 PM UTC-8, Andrew wrote:
>
> Hi Travis,
>
> Thanks for the ultra quick reply. I'm impressed that so much work being 
> done on this as I assumed that it was all in the too hard basket. I'll have 
> a  quick look at calls and see how hard it is to wrap something around 
> chevie's implementation.
>
> Andrew
>
> On Monday, 10 November 2014 15:43:30 UTC+11, Travis Scrimshaw wrote:
>>
>> Hey Andrew,
>>
>> Am I right in thinking that sage does not (yet) know about the left, 
>>> right and two-sided Kazhdan-Lusztig cells of Coxeter groups? As sage can 
>>> compute Kazhdan-Lusztig polynomials I assumed that it knew about cells as 
>>> well, but it doesn't seem to. Please tell me if I am missing something.
>>>
>>
>> AFAIK, there's no code in Sage or ticket about cells. +1 to adding them.
>>
>>>
>>> Incidentally, I also noticed that we have some identity issues -- that I 
>>> am sure are well known:
>>>
>>> sage: WeylGroup("A5")
>>> Weyl Group of type ['A', 5] (as a matrix group acting on the ambient 
>>> space)
>>> sage: CoxeterGroup("A5")
>>> Coxeter group over Universal Cyclotomic Field with Coxeter matrix:
>>> [1 3 2 2 2]
>>> [3 1 3 2 2]
>>> [2 3 1 3 2]
>>> [2 2 3 1 3]
>>> [2 2 2 3 1]
>>>
>>> I am guessing that one of these is just wrapping code from chevie, but I 
>>> haven't checked. Is there any reason not to amalgamate these two classes? 
>>> Currently the CoxeterGroup code seems marginally faster but perhaps the 
>>> WeylGroup classes have more functionality:
>>>
>>
>>I implemented the current CoxeterGroup and it uses Sage's (hence 
>> gap's) matrix group code. However the WeylGroup does have more information 
>> (features) since it is considered acting on the root/weight lattice, such 
>> as reflection_to_root on elements. Combining these classes might be taken 
>> care of by http://trac.sagemath.org/ticket/15703.
>>
>>>
>>> sage: WeylGroup("A5").cardinality()
>>> 720
>>> sage: CoxeterGroup("A5").cardinality()
>>>
>>> ---
>>> NotImplementedError   Traceback (most recent call 
>>> last)
>>>  in ()
>>> > 1 CoxeterGroup("A5").cardinality()
>>>
>>> /usr/local/src/sage/local/lib/python2.7/site-packages/sage/categories/
>>> sets_cat.pyc in cardinality(self)
>>>1370 NotImplementedError: unknown cardinality
>>>1371 """
>>> -> 1372 raise NotImplementedError("unknown cardinality")
>>>1373
>>>1374 # Functorial constructions
>>>
>>> NotImplementedError: unknown cardinality
>>>
>>> There's currently http://trac.sagemath.org/ticket/16630 which should 
>> fix some (all?) of these issues (and I will get to that after next week).
>>
>> Best,
>> Travis
>>
>>

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Making code for some seminormal representations faster

[Travis Scrimshaw]

Hey Andrew,

One of the things that I don't like about (my understanding of) the 
> CombinatorialFreeModule approach to modules is that it is very hard for the 
> (uneducated/unenlightened/unwashed) user to construct their own bases for 
> modules: To construct a new basis you have to explicitly define it using 
> realisations hidden deep inside the code, together with the appropriate 
> coercion maps and I think that the average user won't be able to do this. 
> It would be nice if this provided a mechanism for doing this.
>
>I feel that's somewhat unfair as construct *a* basis is easy, you just 
need to pass an indexing set. However you want to construct multiple basis, 
so multiple parents/classes, *and* change of basis coercions between them, 
the latter part is what takes the work that Sage has default mechanisms for 
doing so (Parent._coerce_map_from_ or Morphism.register_as_coercion).

   That being said, the WithRealizations framework is a way to deal with 
multiple but not necessarily a "best" basis that can be easily extended. 
Yet IMO it feels slightly heavy-handed because of the categories involved 
instead of just using ABC's (there could a reason for this that I'm not 
seeing). For things with a best basis, I decided to just use the main 
object as the global entry point with the other basis as methods, see the 
free algebra and it's PBW basis. This is documented in 
categories/with_realizations.py, but perhaps a modification/expansion as a 
thematic tutorial would be beneficial. In either case, the hard work still 
lies in the defining the COB coercions.

Best,
Travis

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Making code for some seminormal representations faster

[Travis Scrimshaw]

Hey Andrew,

My comment wasn't intended as a criticism of the code or of anyone:  it is 
> great that Mike, Nicolas, Christian and others developed this. Nor was it 
> meat as a complaint as I think that our general philosophy is that if you 
> don't like something then discuss and put a patch on trac.
>

I wasn't trying to imply you were, and I'm sorry if I did. I wanted to 
point out that it is a more general Sage issue beyond 
CombinatorialFreeModule, in the sense that it would be the same issues if 
we were trying to do this with (subclasses of) FreeModules, Rings or 
Algebras.

>
> Your second paragraph is really the point that I was making: given an 
> existing CombinatorialFreeModule, which by definition already has at least 
> one basis, it is hard for non-developers to define a new basis that plays 
> well with the existing ones. For me the coercions aren't really the issue, 
> it shouldn't be hard to streamline this and, in any case, to define a new 
> basis for a given module you have to say how it relates to an existing 
> basis.
>

The most basic/simple setup would be different parents (with perhaps some 
common (abstract) base class) with coercions between them and some common 
entry point.

>
> I have used the With Realizations framework quite a bit in my own code 
> and, of course, in the KL-basis machinery. For people developing code  I 
> think this is very workable, but I doubt that a non-developer would get 
> very far with it.
>

   There definitely is an entry barrier. I should also state that the 
WithRealizations framework also allows us to specify when particular 
morphisms are COB's (via the category of the Homset which we can't so 
easily do with ABC's).

>
> Down the track, what I would like to see is a way of *dynamically* adding 
> bases to a CombinatorialFreeModule without these new bases having to be 
> part of the sage source code. For example, it is possible to do this in 
> chevie. From my quick look at the manifold code, it seems that it allows 
> something in this direction. When I have time I'll see if I can find a way 
> of doing this...
>
> Ah I see what you're after. I guess what we could do is have a method to 
an invertible module morphism (on basis) which creates some generic 
subclass of CombinatorialFreeModule which uses this morphism to translate 
(co)multiplication for (co)algebras.

Best,
Travis

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Making code for some seminormal representations faster

[Travis Scrimshaw]

Here's a thought for something that could work for elements. Make it a 
wrapper around the element you'd do computations in and have a lazy 
attribute for the converted element, and I think you can use __getattr__ 
(or __getattribute__?) to rediect to the wrapped element and I think this 
works with tab completion...I think there's something like this for 
categories?

Best,
Travis

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-combinat-devel] Re: A small hint in Symmetric Functions

[Travis Scrimshaw]

Hey Nicolas,
   I confirm this issue with 6.5.beta0. I think that change is sufficient 
(as a haunting voice echoes in the wind, "along with adding a doctest"). 
Welcome back.

Best,
Travis


On Thursday, November 20, 2014 3:19:16 AM UTC-8, Nicolas Borie wrote:
>
> Hello all, 
>
> As I was constructing some Free Modules over the symmetric functions, I 
> fall on this (sage 6.4.beta2 for my version (yes, that's probably old)): 
>
> sage: SymmetricFunctions(QQ) in CommutativeRings() 
> False 
> sage: SymmetricFunctions(QQ).a_realization() in CommutativeRings() 
> True 
>
> I would have loved that the two lines return True. If I say no mistakes, 
> the symmetric functions should be an abstract parent with severals 
> realizations. The category is *probably* initialized in sf.py with the 
> line: 
>
> Parent.__init__(self, category = GradedHopfAlgebras(R).WithRealizations()) 
>
> Is this enought to change this category for the following one (with QQ 
> replaced by R in the source code naturally) ? 
>
> sage: GradedHopfAlgebras(QQ).Commutative().WithRealizations() 
> Join of Category of hopf algebras over Rational Field and Category of 
> graded algebras over Rational Field and Category of commutative algebras 
> over Rational Field and Category of monoids with realizations and 
> Category of coalgebras over Rational Field with realizations 
>
> Perhaps this question is relatively empty but I didn't contribute to 
> Sage for something like a year. I just reviewed 2 tickets the last 6 
> month and I am still scared of using git (don't laugh please!). So I 
> asked before since a such one line patch cost 10 minutes for git lovers 
> but probably 2 hours with the cheat-sheet of Volker for me. Ok, I just 
> heard someone saying that it will need one than one line since it could 
> be nice to add the proper test in the documentation... Rhoo 
>
> Cheers, 
> Nicolas B. 
>

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Making code for some seminormal representations faster

[Travis Scrimshaw]

Hmmm... I don't see anything from a quick read of the code why this is 
going wrong. I'll take a more detailed look today.

Best,
Travis


On Friday, November 21, 2014 5:55:51 AM UTC-8, Andrew wrote:
>
> I'm currently going around in circles with some CombinatorialFreeModule 
> woes. The previous code for these "alternating seminormal" forms works, but 
> in order to cope with the many variations of seminormal representations 
> that I decided to implement, I've have had to jazz things up quite a lot. 
> Now my basic class structure looks something like this:
>
> from sage.combinat.free_module import CombinatorialFreeModule
> from sage.rings.polynomial.polynomial_ring_constructor import 
> PolynomialRing
>
> class A(CombinatorialFreeModule):
> def __init__(self, base_ring, basis_keys, prefix='a', **kwargs):
> super(A,self).__init__(base_ring, basis_keys, prefix=prefix, **
> kwargs)
>
> class Element(CombinatorialFreeModule.Element):
> pass
>
> class B(A):
> def __init__(self, base_ring, basis_keys, prefix='b', **kwargs):
> super(B,self).__init__(base_ring, basis_keys, prefix=prefix, **
> kwargs)
>
> class C(B):
> def __init__(self, shape, prefix='c', **kwargs):
> base_ring=PolynomialRing(Integers(), 'q')
> super(B,self).__init__(base_ring, shape.standard_tableaux(), 
> prefix=prefix, **kwargs)
>
> This simplified code works fine. For example,
>
> sage: C(Partition([3,2])).an_element()
> 2*c[[[1, 2, 5], [3, 4]]] + 3*c[[[1, 3, 4], [2, 5]]] + 2*c[[[1, 3, 5], [2, 
> 4]]]
>
> Unfortunately my real code does not work, having issues like:
>
> sage: rep=SeminormalRepresentation([2,1]); rep
> SeminormalRepresentation([2,1])# seems to work OK
> sage: rep.an_element() # try to construct an element
>  iwahori_hecke_algebra_representations.
> SeminormalRepresentation_with_category.element_class at 0x119a88c80>) 
> failed: AttributeError: 'SeminormalRepresentation_with_category' object 
> has no attribute '_prefix'>
> sage: rep(StandardTableau([[1,2],[3]]))
> AttributeErrorTraceback (most recent call last
> )
> ...
> AttributeError: 'SeminormalRepresentation_with_category' object has no 
> attribute '_basis_keys'
>
> Does anyone have an idea of what is going wrong. Part of the issue might 
> be all of the super calls, as perhaps some of the the classes higher up are 
> not using super, but I tried taking out all ofthe super calls and, 
> instead,  explicitly calling the previous classes (they are linearly 
> ordered), and unfortunately this doesn't help.
>
> For anyone feeling masochistic, the full code is at trac:17303 
>  (it uses 6.5beta0)
>
> Andrew
>

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Making code for some seminormal representations faster

[Travis Scrimshaw]

Hey Andrew and Nicolas,
   I've probably mentioned this before, but I think we should figure out 
how we want to handle categories for representations in general. I would 
like this for Lie algebras (equiv. universal enveloping algebras), quantum 
groups, and general groups (equiv. group algebras). Something which would 
be benefit from having a category for Hecke algebra representations would 
be methods for constructing the Grothendieck group, a list of simples (up 
to isomorphism), and a canonical place to look for constructing examples 
(via ``an_element()``).

   So my thoughts (if you've heard this before, feel free to skip) on this 
would be to construct a category parameterized by a Hecke algebra ``H`` 
which is a subcategory of the category of modules over ``H.base_ring()``. 
For general representation categories, we'd have an abstract method 
``representation_action()`` (the name can change, I didn't think too hard 
about this) that the user must implement and which we use throughout the 
category and with some default implementation of ``get_action()`` which 
calls ``representation_action()`` when passed an element of ``H``. In this 
case specifically, we could define a generic ``representation_action()`` 
which converts an element to the T_i basis and calls ``T_action(i)`` 
(again, probably a better name out there).

   Although for now we can just have a base class for all Hecke algebra 
representations, and there is not a clear and obvious gain to me at present 
from defining such a category.

Best,
Travis


On Friday, November 21, 2014 4:16:13 PM UTC-8, Andrew wrote:
>
>
>
> On Saturday, 22 November 2014 10:24:43 UTC+11, Nicolas M. Thiery wrote:
>>
>> Hi Andrew, 
>> Hmm, I haven't taken the time to think with a pen and paper, but I 
>> don't guarantee that the what the super call do is as straightforward 
>> as it ought to, given that the instance of A being initialized will 
>> end up being in a subclass A_with_category, and similarly for the 
>> others.  Does it work if instead you call explicitly A.__init__ in 
>> B.__init__, and so on? 
>>
>
> Hi Nicolas,
>
> I fixed my problem so the code is working now. It is possible that there 
> are some issues with the super calls but as far as I can tell it is working 
> as I expect.
>
> One question that I should ask you, however, is the following. I have a 
> suspicion that I should define a category for the Hecke algebra 
> representations, however, I don't know what the benefits are of doing this 
> or how to do it. Certainly the code seems to work without this (not that I 
> have added extensive tests yet or properly implemented the mathematics), 
> but if this is necessary, or desirable, I would like to understand what 
> this gives me over and above having a dedicated class for Hecke algebra 
> representations.
>
> Andrew
>
>  
>

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-combinat-devel] Re: necklaces

[Travis Scrimshaw]

Hey Mike,
   We had the problem for Lyndon words 
(http://trac.sagemath.org/ticket/12997), but it was hacked around. So 
either we fix _sfc/_simple_fixed_content or we hack around it by stripping 
leading 0's and then modifying the yielded elements (by adding # leading 
0's).

Best,
Travis


On Tuesday, December 2, 2014 1:20:27 PM UTC-8, Mike Zabrocki wrote:
>
> I was double checking a problem from my combinatorics class (we are doing 
> Pólya enumeration) and I came across what I think is a bug in the 
> necklaces.py code.
>
> I'll open a ticket, but I want to double check in case someone knows more 
> about this code than I do.
>
> sage: Necklaces([0,2,1]).list()
> [[1, 2, 2], [1, 2, 3], [1, 3, 2]]
> sage: Necklaces([0,2,1]).cardinality()
> 1
>
> I think that while the second answer is correct, the first one should 
> return [[2, 3, 3]].
>
> The only problem that I can see is that code seems to not be written to 
> handle input vectors that have 0 entries.  The documentation needs to be 
> modernized a bit.
>
> -Mike
>

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-combinat-devel] Re: ClassicalCrystalOfAlcovePaths?

[Travis Scrimshaw]

Hey William,
   I believe this is: http://trac.sagemath.org/ticket/17521 (which was 
caused by http://trac.sagemath.org/ticket/16689).

Best,
Travis

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-combinat-devel] Re: Import error using recusive trees

[Travis Scrimshaw]

Hey Henrik,
   You might also be interested in these tickets on some combinatorial Hopf 
algebras:

http://trac.sagemath.org/ticket/13793
http://trac.sagemath.org/ticket/13855

Best,
Travis


On Wednesday, February 11, 2015 at 3:40:49 AM UTC-8, Henrik Sperre 
Sundklakk wrote:
>
> Oh, thanks. That seems to be just what I need.
>
> I should perhaps explain what I want to do:
> In my master's thesis I work to automate parts of the analysis of 
> numerical methods through B-series. This fall I wrote some pure Python code 
> to perform some of the more basic calculations. I had some Maple scipts 
> wirtten by my supervisor to go by, and was also aware of some relevant 
> functionality in Nodepy (by David Ketcheson). I implemented unordered, 
> unlabeled rooted trees (based on multisets represented by a dictionary) and 
> B-series (as python functions on the trees). This I used to find the order 
> of an arbitrary B-series method, composition with hf(), the Lie derivative, 
> and the modified equation.
>
> My interest in using Sage was aroused when I found myself making 
> half-hearted implementations of forests, linear combinations of trees, and 
> so forth (I don't have a strong background in algebra, and simply made 
> classes with the functionality I needed).
>
> Since you have done stuff much more closely related to B-seires than I 
> originally thought, I can't help but wonder if you have also looked in to 
> the Hopf-algebra of Connes and Kreimer? Or if you already have plans to do 
> so?
>
> Regards,
> Henrik S. Sundklakk
>

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-combinat-devel] Re: map_coefficients factor

[Travis Scrimshaw]

Hey Mike,
   At least as a workaround you could do something like this:

sage: s=SymmetricFunctions(QQ).s()
sage: x = s[2,1] + 2*s[3]
sage: for i,c in x: print i, factor(c)
[3] 2
[2, 1] 1

Best,
Travis


On Wednesday, April 15, 2015 at 5:00:18 PM UTC-4, Mike Zabrocki wrote:
>
> Hi all,
> There is very strange behavior if you want factored coefficients of a free 
> module.  Let me give an example in the ring of symmetric functions:
>
> sage: s=SymmetricFunctions(QQ).s()
> sage: (s[2,1] + 2*s[3]).map_coefficients(factor)
> 2*s[3]
>
> What is happening here is that 'factor' returns a factorization object. 
>  factor(1) is an empty list and hence is 'false'.  Now if you look at the 
> code for 's._from_dict' it removes objects which are empty.
>
> If you look at the documentation for 'map_coefficients' you can see that 
> this is not technically a bug because map_coefficients needs to be an 
> endofunction on the coefficient ring.  In this case, factor is mapping from 
> QQ to factor objects and so I wouldn't want to play with the result of that 
> command.  On the other hand, in symmetric functions (especially with 
> multiple parameters like Macdonald or Hall-Littlewood) one would frequently 
> like to factor coefficients to know that the coefficients have a nice form.
>
> Does anyone have any suggestions about what should happen with this case?
> I was discussing it with a few people, but we ruled out changing 
> factor, map_coefficients or _from_dict.
>
> I find that to work with coefficients in a polynomial ring, the functions 
> factor, simplify, expand are unsatisfactory because the output is rarely in 
> a form that shows me what I want to see (Maple and Mathematica seem better 
> at this).  Perhaps what I would like to have is a function 'niceify' that 
> displays a coefficient in a pretty form.
>

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-combinat-devel] Re: European Horizon 2020 project OpenDreamKit accepted

[Travis Scrimshaw]

Congratulations!   *fireworks*

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-combinat-devel] Re: strange category

[Travis Scrimshaw]

Hey Mark,
   The reason this was done was because the category doesn't depend on the 
particular base ring, but on its category. The issue is that the people who 
work on finite fields create a lot of fields over large ranges of primes, 
and so would have to create a new category every time with the exact same 
functionality. So instead we opted to have it depend on the category of the 
base_ring, which albeit is a somewhat bad name to still call it base_ring, 
but we can still create the category over a proper base ring.

Best,
Travis


On Thursday, June 11, 2015 at 8:37:19 AM UTC-7, Mark Shimozono wrote:
>
> I think the following is a bug in assigning a category to a module.
> I am running sage Version 6.8.beta3, Release Date: 2015-06-04
>
> {{{
> sage: M = QQ^2
> sage: cat = M.category(); cat
> Category of vector spaces with basis over quotient fields
> sage: from sage.categories.category_types import Category_over_base_ring
> sage: isinstance(cat, Category_over_base_ring)
> True
> sage: cat.base_ring()
> Category of quotient fields
> }}}
>

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-combinat-devel] Re: Test digraph for cycles containing a vertex?

[Travis Scrimshaw]

Hey Simon,
   That is correct and the only way I know of AFAIK.

Best,
Travis


On Friday, June 19, 2015 at 2:31:28 PM UTC-7, Simon King wrote:
>
> Hi! 
>
> Let D be a digraph, potentially with multiple edges and loops. Let v be 
> a vertex. 
>
> How should one test whether v is contained in a cycle (including loops)? 
>
> Is it correct that v is in a cycle or loop if and only if 
>  (len(D.strongly_connected_component_containing_vertex(v))>1) or (v in 
>  D.neighbors_out(v)) 
> ? 
> Is there a better way to test it? 
>
> Best regards, 
> Simon 
>
>
>

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-combinat-devel] Re: Test digraph for cycles containing a vertex?

[Travis Scrimshaw]

Hey Simon,
   I would imagine this would be relatively efficient:

def has_path(u, v):
it = D.all_paths_iterator([u], [v])
try:
it.next()
return True
except StopIteration:
pass
return False

Best,
Travis


On Saturday, June 20, 2015 at 5:51:09 AM UTC-7, Simon King wrote:
>
> Hi Nicolas, 
>
> On 2015-06-20, Nicolas M. Thiery > 
> wrote: 
> > - search for a path from one of the out neighbors of v to v 
>
> Sure, but how? In fact I was looking for a method of digraphs telling me 
> whether there is a path from vertex v to vertex w, but I couldn't find 
> one. 
>
> "w in D.connected_component_containing_vertex(v)" doesn't work, as the 
> connected component doesn't take into account the orientations. 
> "w in D.strongly_connected_component_containing_vertex(v)" doesn't work, 
> as that would test if v and w belong to a CYCLE (not just a path). 
> Using D.shortest_path probably isn't efficient, as we are looking for 
> the existence of *some* path and do not need the *shortest* one. 
>
> Best regards, 
> Simon 
>
>

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-combinat-devel] Re: Specification of combinatorial free module?

[Travis Scrimshaw]

Hey all,
   Speaking of CFM, what should we do http://trac.sagemath.org/ticket/18750 
(sorry to throw it onto the pile Nicolas)? Should CFM always make sure any 
input given to it by a user be the proper basis element?

My current fix on #18750 doesn't work, but I believe it is the correct way 
forward when the index set is a Parent with a proper element class. (My 
current proposal breaks because Cartesian products (currently, but planned 
to change) and FiniteEnumerateSet are not in this category.) I believe my 
approach could be tweaked to work, but I want to make sure our 
specifications are set.

Best,
Travis

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] weird behavior under combining remove and for loop

[Travis Scrimshaw]

I'm surprised it's not raising an error as well because I knew of the error 
that the dictionary raises that Simon mentioned having personally 
encountered it in my code myself.

There is not a copy of i with its current value that build the current 
> lambda each step, no. In fact, all lambda use the same i in memory and 
> the value of i is changing each step. At the end, since the value of i 
> at last iteration is 4, it returns a list containing 5 times the same 
> function... 
>
> Initialization, we have [] 
> i = 0, we have [x->1] 
> i = 1, we have [x->x, x->x] 
> i = 2, we have [x->x^2, x->x^2, x->x^2] 
> ... 
> i=4, we have [x->x^4, x->x^4, x->x^4, x->x^4,x->x^4] 
>

This is similar to my favorite one:

>>> L = [[]]*5
>>> L
[[], [], [], [], []]
>>> L[0].append(1)
>>> L
[[1], [1], [1], [1], [1]]

which bit me hard once. Fix is to always write L = [[] for i in range(5)] 
(I remember someone telling me or reading that the two were equivalent). It 
makes sense from an optimization standpoint, but it's just more fun with 
mutable objects and pointers/references.

> What about this one : 
>  True is False 
> > False 
>  False is False 
> > True 
>  True is False is False 
> > False 
>  (True is False) is False 
> > True 
>  True is (False is False) 
> > True 
> > 
> > This last one is easy but still tricky the first time you see it... 
>
> This one I actually find pretty reasonable. 
>

I agree. (As you are probably well aware) Python takes "X is Y is Z" and 
parses it into "X is Y and Y is Z", just like it would for any other 
comparison operators.

Best,
Travis

 

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] KL polynomials for translations in the affine Weyl groups

[Travis Scrimshaw]

We also have the native (almost certainly significantly slower) version:

sage: R. = LaurentPolynomialRing(QQ)
sage: W = WeylGroup(['A',3,1])
sage: K = KazhdanLusztigPolynomial(W, q)
sage: P = RootSystem(['A',3,1]).weight_lattice()

sage: K.P(W.one(), 
W.from_reduced_word(P.reduced_word_of_translation(P.simple_root(1
1 + q

as well as direct computation on the Iwahori-Hecke algebra:

sage: R. = LaurentPolynomialRing(QQ)
sage: I = IwahoriHeckeAlgebra(W, t^2)
sage: T = I.T()
sage: Cp = I.Cp()
sage: x = 
Cp[W.from_reduced_word(P.reduced_word_of_translation(P.simple_root(1)))]; x 
Cp[2,0,3,2,0,1]
sage: T(x)
(t^-6)*T[2,0,3,2,0,1] + (t^-6)*T[2,3,2,0,1] + (t^-6)*T[2,0,3,2,0] + 
(t^-6)*T[2,0,3,0,1] + (t^-6)*T[0,3,2,0,1] + (t^-6)*T[2,0,3,2,1] + 
(t^-6)*T[2,3,2,0] + (t^-6)*T[2,3,0,1] + (t^-6)*T[3,2,0,1] + 
(t^-6)*T[2,0,3,0] + (t^-6)*T[0,3,2,0] + (t^-6)*T[2,0,3,2] + 
(t^-6)*T[0,3,0,1] + (t^-6)*T[2,0,3,1] + (t^-6)*T[2,3,2,1] + 
(t^-6)*T[0,3,2,1] + (t^-6)*T[2,3,0] + (t^-6)*T[3,2,0] + (t^-6)*T[3,0,1] + 
(t^-6+t^-4)*T[2,0,1] + (t^-6)*T[0,3,0] + (t^-6)*T[2,0,3] + (t^-6)*T[0,3,2] 
+ (t^-6)*T[0,3,1] + (t^-6)*T[2,3,2] + (t^-6)*T[3,2,1] + (t^-6)*T[2,3,1] + 
(t^-6)*T[3,0] + (t^-6+t^-4)*T[2,0] + (t^-6+t^-4)*T[0,1] + (t^-6)*T[0,3] + 
(t^-6)*T[3,2] + (t^-6)*T[2,3] + (t^-6)*T[3,1] + (t^-6+t^-4)*T[2,1] + 
(t^-6+t^-4)*T[0] + (t^-6)*T[3] + (t^-6+t^-4)*T[2] + (t^-6+t^-4)*T[1] + 
(t^-6+t^-4)

Although this is the slowest, but it gives you the most information.

Best,
Travis

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-combinat-devel] Re: bug in free module construction?

[Travis Scrimshaw]

Hey Mark,
   AFAIK, there is not currently a ticket on this. However it would not be 
hard to implement R^4 as a free module over R as a default:

sage: h = SymmetricFunctions(QQ).h()
sage: F = FreeModule(h, 4)
sage: v = F([h[2,1], h[3,2,2,1], -2, h[7]]); v
(h[2, 1], h[3, 2, 2, 1], -2*h[], h[7])

Although the natural scalar action of R on R^4 is not currently there:

sage: B = F.basis()
sage: h[2,1] * B[0] + h[3,2,2,1] * B[1] - h[7] * B[3]   # This breaks with 
an error
sage: v + B[0] - B[2]   # This crashes my Sage

Best,
Travis


On Wednesday, July 8, 2015 at 10:46:19 AM UTC-7, Mark Shimozono wrote:
>
> The exponential shortcut for free module construction, such as
>
> {{{ QQ^3 }}}
>
> does not work for rings with slightly more complicated constructions.
> For example, it does not work for group algebras, symmetric function rings,
> etc.
>
> Is there a ticket on this?
>
>
>
>
>

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-combinat-devel] Re: function arguments and decorators

[Travis Scrimshaw]

Hey Salvatore,
   Have you tried the `key` attribute for `@cached_function` and/or 
`@cached_method`?

@cached_method(key=tuple)
def foo(x):
return tuple(x)*2

The only downside is that there will be some redundancy (you have to do the 
cast twice, once for the key, once in the method).

I think a useful extension of this concept would be similar to 
UniqueRepresentation, where we preprocess the input and cache the result...

Best,
Travis


On Wednesday, August 12, 2015 at 2:56:05 AM UTC-7, Salvatore Stella wrote:
>
> Dear All, 
> I have several functions that take as input a tuple of integers. In many 
> of 
> these functions I check if this tuple belongs to some given list so its 
> type 
> is important. On the other hand I would like to allow users to pass a 
> lists or 
> a vector instead of a tuple. 
>
> One obvious way to deal with this is to make a coercion at the beginning 
> of 
> each function but this would lead to code duplication. Moreover it would 
> also 
> prevent me from using memoization. Is there a decorator in sage that I 
> could 
> use instead? 
>
> If I were coding in python 3.4 I would write a decorator like this: 
>
> def make_hashable(func): 
> @wraps(func) 
> def wrapper(*args, **kwargs): 
> hashable_args = [] 
> for x in args: 
> try: 
> hashable_args.append(tuple(x)) 
> except: 
> hashable_args.append(x) 
>   
> hashable_kwargs = {} 
> for x in kwargs: 
> try: 
> hashable_kwargs[x] = tuple(kwargs[x]) 
> except: 
> hashable_kwargs[x] = kwargs[x] 
>   
> return func(*hashable_args, **hashable_kwargs) 
> return wrapper 
>
> This works almost as well in earlier version of python except that @wraps 
> messes up the function signature. Is there any elegant solution to this 
> problem? 
> Thanks 
> S. 
>
>
>

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Re: CombinatorialFreeModule relies on implementation details of elements

[Travis Scrimshaw]

IIRC, #18066 was mainly started so that support() doesn't needlessly sort 
things, other such cleanups, and better refactor things for 
generalizations, such as to Lie algebras (which is currently designed to 
use CFM elements). In the end, I believe the goal is to make CFM irrelevant 
and have things handled by the (cython) free modules and the category 
Modules(WithBasis).

I really should spend a weekend doing nothing but reworking (combinatorial) 
free modules and the respective categories...now to find the time... 
However, any progress you make in this direction will be appreciated (and I 
should be able to help with/do the review).

Best,
Travis

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-combinat-devel] GAP3 spkg

[Travis Scrimshaw]

Hey combinat,
   Has anyone tried to install the now included optional GAP3 spkg? I get a 
checksum error when I do.

Best,
Travis

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] GAP3 spkg

[Travis Scrimshaw]

Hey Anne,
   It looks like you're also having the same issues (as those errors are 
just from me telling you the wrong name of the optional spkg and a 
docbuilding issue). Thanks for confirming.

This is now http://trac.sagemath.org/ticket/19164.

Best,
Travis

FYI - You can get rid of those error messages by deleting the appropriate 
log files (perhaps also those subdirectories if they still exist) and 
running a `make doc-clean`.


On Tuesday, September 8, 2015 at 10:03:43 AM UTC-5, Anne Schilling wrote:
>
> Hi Travis, 
>
> I get the following error message when installing the latest development 
> version 
> even after 'make docclean' 
>
> [repl ] reading sources... [  2%] environ 
> [tensor_fr] reading sources... [ 17%] morphisms 
> [tensor_fr] reading sources... [ 23%] sage/tensor/modules/comp 
> [repl ] reading sources... [  5%] index 
> Error building the documentation. 
>
> Note: incremental documentation builds sometimes cause spurious 
> error messages. To be certain that these are real errors, run 
> "make doc-clean" first and try again. 
> Traceback (most recent call last): 
>   File "/Applications/sage/src/doc/common/builder.py", line 1626, in 
>  
> getattr(get_builder(name), type)() 
>   File "/Applications/sage/src/doc/common/builder.py", line 292, in 
> _wrapper 
> getattr(get_builder(document), 'inventory')(*args, **kwds) 
>   File "/Applications/sage/src/doc/common/builder.py", line 503, in 
> _wrapper 
> x.get(9) 
>   File "/Applications/sage/local/lib/python/multiprocessing/pool.py", line 
> 558, in get 
> raise self._value 
> OSError: [polynomia] 
> /Applications/sage/src/doc/en/reference/polynomial_rings/index.rst:7: 
> WARNING: toctree contains reference to nonexisting document 
> u'sage/rings/polynomial/polynomial_ring_constructor' 
>
> make[2]: *** [doc-html] Error 1 
> make[1]: *** [all] Error 2 
>
> real0m8.326s 
> user0m5.805s 
> sys0m2.486s 
> *** 
> Error building Sage. 
>
> The following package(s) may have failed to build (not necessarily 
> during this run of 'make all'): 
>
> * package: gap-database 
>   log file: /Applications/sage/logs/pkgs/gap-database.log 
>   build directory: 
> /Applications/sage/local/var/tmp/sage/build/gap-database 
>
> * package: gap_database 
>   log file: /Applications/sage/logs/pkgs/gap_database.log 
>   build directory: 
> /Applications/sage/local/var/tmp/sage/build/gap_database 
>
> * documentation: dochtml 
>   log file: /Applications/sage/logs/pkgs/../dochtml.log 
>
> The build directory may contain configuration files and other potentially 
> helpful information. WARNING: if you now run 'make' again, the build 
> directory will, by default, be deleted. Set the environment variable 
> SAGE_KEEP_BUILT_SPKGS to 'yes' to prevent this. 
>
> make: *** [all] Error 1 
>
>
> Then for gap3 
>
> lolita:sage anne$ sage -i gap3 
> Forcing sage-location, probably because a new package was installed. 
> Updating various hardcoded paths... 
> (Please wait at most a few minutes.) 
> DO NOT INTERRUPT THIS. 
> Done updating paths. 
> Found local metadata for gap3-jm5.p0 
> Attempting to download package gap3-jm5.tar.gz from mirrors 
> http://mirrors.xmission.com/sage/spkg/upstream/gap3/gap3-jm5.tar.gz 
> [..] 
> Traceback (most recent call last): 
>   File "/Applications/sage/build/bin/sage-download-file", line 28, in 
>  
> SageDownloadFileApplication().run() 
>   File "/Applications/sage/build/bin/../sage_bootstrap/cmdline.py", line 
> 193, in run 
> tarball.download() 
>   File "/Applications/sage/build/bin/../sage_bootstrap/tarball.py", line 
> 160, in download 
> raise ChecksumError('checksum does not match') 
> sage_bootstrap.tarball.ChecksumError: checksum does not match 
>
> Best, 
>
> Anne 
>
>
> On 9/8/15 6:48 AM, Travis Scrimshaw wrote: 
> > Hey combinat, 
> >Has anyone tried to install the now included optional GAP3 spkg? I 
> get a checksum error when I do. 
> > 
> > Best, 
> > Travis 
>

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-combinat-devel] Skew partitions for symmetric functions

[Travis Scrimshaw]

While looking into the code on skew Schur functions, I noticed this:

elif x in sage.combinat.skew_partition.SkewPartitions():
import sage.libs.lrcalc.lrcalc as lrcalc
skewschur = lrcalc.skew(x[0], x[1])
return self._from_dict(skewschur)

This has the following result:

sage: s = SymmetricFunctions(QQ).s()
sage: e = SymmetricFunctions(QQ).e()
sage: sp = SkewPartition([[5,3,3,1], [3,2,1]])
sage: e(s(sp))
e[2, 1, 1, 1, 1] - e[2, 2, 1, 1] - e[3, 1, 1, 1] + e[3, 2, 1]
sage: e(sp)
e[2, 2, 1, 1] + e[2, 2, 2] + e[3, 1, 1, 1] + 3*e[3, 2, 1] + e[3, 3] + 2*e[4, 
1, 1] + 2*e[4, 2] + e[5, 1]

The skew() function of lrcalc returns the corresponding skew Schur 
function, so the above is a bug. My question is should we

(A) raise an error for skew shapes on all bases,
(B) allow only of the Schur basis, or
(C) construct the skew Schur function and convert to the corresponding 
basis.

I'm not so sure about (C) because this would mean skew partitions behave 
very differently than for partitions. I'm leaning towards (B). Thoughts?

I'm also going to add a method skew_schur() which constructs the skew Schur 
function, as to make getting at skew Schur functions easier (there is also 
right now the skew_by method, but that acts on elements).

Best,
Travis

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-combinat-devel] Re: Skew partitions for symmetric functions

[Travis Scrimshaw]

Hey Mike,

I would say that the skew partition input into bases (other than Schur 
> functions, and for Schurs the documentation is insufficient...see sf.html) 
> is undocumented and so the output should be suspect (and not what one would 
> hope).
>
> For Schur functions, I think the output is what I would expect and so of 
> (A), (B) and (C), I think that (B) is the way to go and it should be better 
> documented.
>
> I can add a fourth option:
> if sp is a skew partition then
> (D) basis(sp) returns basis(sp[0]).skew_by(basis.dual_basis()(sp[1]))
> This agrees with the definition of the Schur function indexed by a skew 
> partition and would probably be the most natural analogue of the notation 
> basis(sp)
> I can see two problems with this approach:
> (a) I don't know how often "dual_basis" is implemented and
> (b) one would need to document and mathematically motivate this notation 
> and I could see an argument being made for another definition.
>
> Every classical Sym basis has a dual_basis() implemented, but (b) is 
definitely more of a sticking point.
 

> Hence I still say (B).
>

Then I will do (B) unless anybody has any other suggestions or objections.

>
> Where are you planning to add the method skew_schur()?  Would this go as 
> a method of the Schur basis or of the symmetric functions?
>
> I was going to add it to the generic basis code which does the Schur 
expansion and converts that over to self, just like the 
carlitz_shareshian_wachs or gessel_reutenauer function.
 
Best,

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Re: Skew partitions for symmetric functions

[Travis Scrimshaw]

It also makes it much easier for the user to discover it (in fact, this 
time the user was me; it took examining the code for me to find this 
functionality in the first place).

This is now http://trac.sagemath.org/ticket/19218 and needing review.

Best,
Travis


On Tuesday, September 15, 2015 at 7:22:21 AM UTC-5, Nicolas M. Thiery wrote:
>
> On Mon, Sep 14, 2015 at 07:00:11PM -0700, Anne Schilling wrote: 
> > I would also say (B). But why is skew_schur needed if the usual 
> > Schur function already takes a skew partition as an input? 
>
> It's a usual pattern: when a constructor/call function takes very 
> different kinds of input, it can be nice to split out the 
> implementation of the various constructions into independent 
> functions. This cleanly separates the concerns between the dispatch 
> upon input and each construction. 
>
> Cheers, 
> Nicolas 
> -- 
> Nicolas M. Thiéry "Isil" > 
> http://Nicolas.Thiery.name/ 
>

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-combinat-devel] Re: Fraction field elements are not simplified

[Travis Scrimshaw]

Hey Salvatore,
   I would say this is the same problem as simplifying scalars of fraction 
fields of polynomials over QQ, that gcd(x, x) = 1 rather than x because x 
is a unit. I don't think we have a way around this currently other than 
doing some kind of explicit coercion.

Best,
Travis


On Friday, October 9, 2015 at 1:40:22 PM UTC-5, Salvatore Stella wrote:
>
> Dear all, 
> I just noted the following odd behaviour: 
>
> sage: L = LaurentPolynomialRing(ZZ, 'x').fraction_field() 
> sage: L.inject_variables() 
> Defining x 
> sage: x/x 
> 1 
>
> As one should expect but if we change the base ring then things get messy: 
> sage: L = LaurentPolynomialRing(LaurentPolynomialRing(ZZ,'t'), 
> 'x').fraction_field() 
> sage: L.inject_variables() 
> Defining x 
> sage: x/x 
> x/x 
> sage: _.denominator() 
> x 
>
> The fact that x/x is printed out as x/x is still ok if somewhat annoying. 
> But 
> the return value of denominator() is definitely not what I would expect. 
> Is this intentional? 
> Thanks 
> Salvatore 
>

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-combinat-devel] Re: Fraction field elements are not simplified

[Travis Scrimshaw]

I think I slightly misspoke about the gcd. See the details on 
http://trac.sagemath.org/ticket/16993.

Best,
Travis


On Friday, October 9, 2015 at 4:12:12 PM UTC-5, Travis Scrimshaw wrote:
>
> Hey Salvatore,
>I would say this is the same problem as simplifying scalars of fraction 
> fields of polynomials over QQ, that gcd(x, x) = 1 rather than x because x 
> is a unit. I don't think we have a way around this currently other than 
> doing some kind of explicit coercion.
>
> Best,
> Travis
>
>
> On Friday, October 9, 2015 at 1:40:22 PM UTC-5, Salvatore Stella wrote:
>>
>> Dear all, 
>> I just noted the following odd behaviour: 
>>
>> sage: L = LaurentPolynomialRing(ZZ, 'x').fraction_field() 
>> sage: L.inject_variables() 
>> Defining x 
>> sage: x/x 
>> 1 
>>
>> As one should expect but if we change the base ring then things get 
>> messy: 
>> sage: L = LaurentPolynomialRing(LaurentPolynomialRing(ZZ,'t'), 
>> 'x').fraction_field() 
>> sage: L.inject_variables() 
>> Defining x 
>> sage: x/x 
>> x/x 
>> sage: _.denominator() 
>> x 
>>
>> The fact that x/x is printed out as x/x is still ok if somewhat annoying. 
>> But 
>> the return value of denominator() is definitely not what I would expect. 
>> Is this intentional? 
>> Thanks 
>> Salvatore 
>>
>

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-combinat-devel] Change in behavior for WeylGroups.reflections()

[Travis Scrimshaw]

Hey all,
   This is a general announcement/warning that we are planning on reversing 
the keys/values for the family of reflections in 
http://trac.sagemath.org/ticket/20027. This will make this consistent with 
the behavior for CoxeterGroups.reflections() and have the more natural 
simple iteration over the elements. There will be no deprecation warning 
for this change.

Best,
Travis

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] ClonableIntArray

[Travis Scrimshaw]

Hey Andrew,
Just for reference, you do not need these lines as they are in the 
Tableau code so you can call Tableau(...) directly without having to 
explicitly create the parent object.

@staticmethod
def __classcall_private__(cls, elt):
return MyParent().element_class(MyParent(), elt)

Although considering that the metaclass has not been set to the classcall 
metaclass, it should not be called.

Best,
Travis

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] ClonableIntArray

[Travis Scrimshaw]

Hey Andrew,

I want this functionality too. I tried adding:
>
> __metaclass__ = ClasscallMetaclass
>
> but this produces the error:
>
> TypeError: Error when calling the metaclass bases
> metaclass conflict: the metaclass of a derived class must be a (non-
> strict) subclass of the metaclasses of all its bases
>
> I found that using
> __metaclass__ = InheritComparisonClasscallMetaclass
>
> works, although I am not yet sure if I need rich comparison.
>
> Anyway, apart from this minor quibble about meta classes it seems to be 
> working for now.
>
> Recent changes (IIRC thanks to Jeroen) have made it so that comparisons 
can use the coercion framework if they define a _cmp_, which is done in 
Element. Then, in order to have cython classes (e.g., the Clonable* 
classes) inherit this feature, a new metaclass was needed. See 
http://trac.sagemath.org/ticket/18329.

Best,
Travis

 

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-combinat-devel] Re: Defining basis keys for combinatorial free modules

[Travis Scrimshaw]

Hey Simon,
   You might want to use FreeMonoid(index_set=S) as your basis indexing 
set. Although you will need 7.2.beta5 to do the iteration:

sage: S = (1,2)
sage: F = FreeMonoid(index_set=S)
sage: it = iter(F)
sage: [next(it) for _ in range(10)]
[1, F[1], F[2], F[1]*F[2], F[2]^2, F[1]^2, F[2]*F[1], F[1]^2*F[2], F[2]^2*F[
1], F[1]^3]
sage: [next(it).to_word_list() for _ in range(10)]
[[], [1], [2], [1, 2], [2, 2], [1, 1], [2, 1], [1, 1, 2], [2, 2, 1], [1, 1, 
1]]
sage: F([[1,4],[2,1],[1,1],[2,3]])
F[1]^4*F[2]*F[1]*F[2]^3

This works for any set S, but the iterator will only work for finite sets 
S. However, perhaps there could be some additional functionality for 
IndexedFreeMonoid that could be added to make it work with your use case.

Best,
Travis

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-combinat-devel] Re: ask-sage question: tensor product of polynomial algebras

[Travis Scrimshaw]

Hey Samuel,
   I don't think there currently is a general implementation for tensor 
products of rings/algebras. Although you can hack together a small subclass 
of CombinatorialFreeModule:

class PolynomialAlgebra(CombinatorialFreeModule):
def __init__(self, base_ring, names):
CombinatorialFreeModule.__init__(self, base_ring, FreeAbelianMonoid(
index_set=names), category=Algebras(base_ring).WithBasis())
def gens(self):
return tuple([self.monomial(x) for x in self.indices().gens()])
def one_basis(self):
return self.monomial(self.indices().one())
def product_on_basis(self, x, y):
return self.monomial(x * y)

Sample usage:

sage: P = PolynomialAlgebra(QQ, ('x','y'))
sage: x,y = P.gens()
sage: x^3
B[F['x']^3]
sage: x^3 + 2*x*y
B[F['x']^3] + 2*B[F['x']*F['y']]
sage: tensor([P, P])
Free module generated by Free abelian monoid indexed by {'x', 'y'} over 
Rational Field # Free module generated by Free abelian monoid indexed by 
{'x', 'y'} over Rational Field
sage: _.an_element()
2*B[1] # B[1] + 2*B[1] # B[F['x']] + 3*B[1] # B[F['y']]

However, it won't do "fancy" things like division.

Best,
Travis

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-combinat-devel] Re: Super Module and Clifford Algebra

[Travis Scrimshaw]

Hey Florent,
   Sorry for taking so long to get to this (in honesty, I forgot about 
answering).

>
> Now a question for Travis: 
>
> in super_modules_with_basis.py, you hide the method 
>_even_odd_on_basis 
> As a minor consequence, there is a void ParentMethod class in the 
> documentation. 
> Except for very technical methods, the usage in categories is to have the 
> on_basis (se eg: product_on_basis one_on_basis, coproduct_on_basis...) 
> methods 
> public, in particular because these are the methods that must be written. 
>
> Do you have a strong case for keeping _even_odd_on_basis private ? 
>
> Because it pollutes the namespace for the parent as it has no direct 
bearing on the parent. For that reason, I (somewhat strongly) believe that 
none of the *on_basis methods should be public. However, I am for 
documenting its usage/importance in the category and/or examples. Yet in 
either case, it is only useful for someone looking at the category 
documentation, and I would say having more/better examples of category 
implementations and thematic tutorials will improve the ease of new 
implementations.

Best,
Travis

 

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-combinat-devel] Re: Super Module and Clifford Algebra

[Travis Scrimshaw]

Hey Florent,

I'm very sensible to the namespace pollution question. However, as a user 
> (contrary to a developper) I'm using from time to time those methods 
> directly 
> and I'm considering those as part of the public API. Indeed, its not 
> uncommon 
> that calling one_on_basis or product_on_basis save you some time. And 
> since I 
> value more consistency than small namespace, I'm in favor of having all 
> on_basis methods public. 
>

IMO, they should all be pulled from the namespace (but included in the 
documentation; although I suspect anyone who is optimizing will quickly 
encounter these functions, private or public, by going through the code). 
Yet that takes more time/effort to do than I have to devote to that right 
now. Another reason why I think it should be private is that if the user 
wants to override directly on the elements is_even_odd, then you don't want 
to have such a method even available (although in a way, that is a subissue 
of the namespace pollution). So I feel the *_on_basis methods are more of 
an implementation detail than public API.

Best,
Travis

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-combinat-devel] Eventual change in behavior for permutation descents

[Travis Scrimshaw]

Dear all,
   On #20555 , we have set in motion 
an eventual change of the default behavior for the descent in a permutation 
to be 1-based, instead of 0-based, in order to agree with the usual notion 
of considering a permutation of {1, 2, ..., n} and an element of the type 
A_n Weyl group. This will happen after a 1 year deprecation period, but 
there will remain an optional argument "from_zero" that you can set to 
"True" to force the current behavior.

Best,
Travis

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-combinat-devel] Re: CartanTypes

[Travis Scrimshaw]

We also should determine how we want to distinguish between (and input) 
A_{+oo} and A_{oo}, i.e., index sets of NN and ZZ. In fact, the only place 
where I really see this fundamentally breaking is the CartanMatrix and 
Dynkin Diagram. All of the root/weight lattice stuff should work since 
those are based around Family and CombinatorialFreeModule (although roots() 
and friends probably won't work so well).

I don't really see a problem with just implementing a subclass of 
CartanType_abstract for A_{+oo}/A_{oo} and allowing the methods to just 
raise NotImplementedError's.

Best,
Travis

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-combinat-devel] Re: kronecker coefficient

[Travis Scrimshaw]

Perhaps Andrew can weigh in on putting Kronecker coefficients with 
partition tuples, but it feels somewhat artificial to me. Instead, I like 
the explicitness of the syntax

la.kronecker_coefficient(mu, nu)

and/or having some (lazily imported) global namespace function of 
kronecker_coefficient (both taking arbitrary inputs representing the 
multiplicity of lambda in a longer tensor product).

Best,
Travis

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-combinat-devel] Re: Constructing elements in disjoint enumerated sets that are Cartesian products

[Travis Scrimshaw]

Hey Andrew,
   Well, I've recently been looking at DisjointUnionEnumeratedSets (see 
https://trac.sagemath.org/ticket/22382) and came across this problem. The 
first issue is that DisjointUnionEnumeratedSets does not behave like an 
actual facade parent like it claims to be (at least with default values). 
The second is that __call__ calls a morphism, which in turn calls 
_element_constructor_ and expects a subclass of element to be returned. 
Thus for facade parents that want to return a tuple, this causes a problem 
(see the ticket).

   Actually, looking at what you want more closely now, you want this to be 
a proper parent, so just pass the facade=False. This works with the current 
Sage:

sage: tabs = DisjointUnionEnumeratedSets(Family(Partitions(3), lambda mu: 
cartesian_product([mu.standard_tableaux(),mu.standard_tableaux()])), facade=
False)
sage: s = StandardTableau([[1,2],[3]])
sage: (s,s) in tabs
True
sage: tabs((s,s))
([[1, 2], [3]], [[1, 2], [3]])

Best,
Travis

On Wednesday, February 15, 2017 at 6:01:17 PM UTC-6, Andrew wrote:
>
> I am working with disjoint enumerated sets like the following
>
> sage: tabs = DisjointUnionEnumeratedSets(Family(Partitions(3), lambda mu: 
> cartesian_product([mu.standard_tableaux(),mu.standard_tableaux()])))
> sage: tabs[:]
> [([[1, 2, 3]], [[1, 2, 3]]),
>  ([[1, 3], [2]], [[1, 3], [2]]),
>  ([[1, 3], [2]], [[1, 2], [3]]),
>  ([[1, 2], [3]], [[1, 3], [2]]),
>  ([[1, 2], [3]], [[1, 2], [3]]),
>  ([[1], [2], [3]], [[1], [2], [3]])]
>
> I need to be able to construct elements of this set from a tuple of 
> elements in the underlying sets but I can't work out a nice way to do this. 
> I thought that the following would work but it doesn't:
>
> sage: s = StandardTableau([[1,2],[3]])
> sage: (s, s) in tabs
> True
> sage: tabs( (s,s) )
> ---
> NotImplementedError   Traceback (most recent call last
> )
>  in ()
> > 1 tabs( (s,s) )
>
> /usr/local/src/sage/src/sage/structure/parent.pyx in sage.structure.parent
> .Parent.__call__ (build/cythonized/sage/structure/parent.c:9584)()
> 934 self._element_init_pass_parent = guess_pass_parent
> (self, self._element_constructor)
> 935 except (AttributeError, AssertionError):
> --> 936 raise NotImplementedError
> 937 cdef Py_ssize_t i
> 938 cdef R = parent_c(x)
>
> NotImplementedError:
>
> One way around this is the following, but I would guess that this is far 
> too inefficient to use inside an element_constructor method:
>
> sage: ss = tabs.unrank( tabs.rank( (s,s) ) )
> sage: type(ss)
>  'sage.sets.cartesian_product.CartesianProduct_with_category.element_class'
> >
>
> Is there a better way to do his?
>
> Andrew
>

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-combinat-devel] Re: Constructing elements in disjoint enumerated sets that are Cartesian products

[Travis Scrimshaw]

Hey Andrew,
>
>  
> Unfortunately, now it seems that I can't access the elements of the tuple 
> directly:
>
> sage: tabs = DisjointUnionEnumeratedSets(Family(Partitions(3), lambda mu: 
> cartesian_product([mu.standard_tableaux(),mu.standard_tableaux()])), 
> facade=False)
> sage: s=StandardTableau([[1,2],[3]])
> sage: ss=tabs( (s,s) )
> sage: ss[0]
> ---
> TypeError Traceback (most recent call last
> )
>  in ()
> > 1 ss[Integer(0)]
>
> TypeError: 'sage.structure.element_wrapper.ElementWrapper' object has no 
> attribute '__getitem__'
> > (1)()
> > 1 ss[Integer(0)]
>
> On the other hand, the following works:
>
>
> sage: ss.value[0], ss.value[1]
> ([[1, 2], [3]], [[1, 2], [3]])
>
>
> Yea, it comes from the fact that it is only a simple wrapped element and 
doesn't do anything beyond forwarding the repr/latex/ascii-art outputs. I 
go back and forth on whether or not to pass along some (all?) extra 
methods. Probably the easiest thing to work with is the facade with the 
ticket (at least if you don't care if the element belongs to this specific 
parent).

Thanks for looking at the ticket too.

Best,
Travis


-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-combinat-devel] Re: Improvements to FreeAlgebra

[Travis Scrimshaw]

Hey Simon,

>
> On 2017-03-29, Nicolas M. Thiery > 
> wrote: 
> > It would be interesting to know specifically on which aspects the path 
> > algebra is improving on the current free algebra. The data structure 
> > of indices (i.e. words in the generators)? The data structure for 
> > representing linear combinations? The implementation of the product? 
> > 
> > Maybe some of those improvements could be lifted up to FreeModule in 
> > the first place, or provide an alternative generic implementation of 
> > it that would work better for your use case [1]. 
>
> My own use case is proper path algebras with *several* vertices. So, 
> FreeModule won't cover my own applications. 
>
> My comment was motivated by a question on sage-support. The question 
> has merely been about the fact that 1 is not recognised as an element 
> of a free algebra over ZZ, and while trying to give the user some 
> work-arounds, I played with different ways to create what mathematically 
> is a free associative algebra. 
>
> I agree that this is something that should be fixed (actually 0 is not 
recognized as being in a CFM, which is a bug IMO). I would just check to 
see if the element can be converted to the base ring, possibly putting 
something in CFM rather than FreeAlgebra which also checks if the CFM is in 
UnitalAlgebras.
 

> Why is it faster? 
> 1. Paths are implemented as BoundedIntegerSequences, which in turn 
>are implemented as bitsets. Concatenation ultimately relies on 
>bitshift operations, that are quite efficiently implemented in 
>MPR. 
> 2. Path algebra elements are implemented as ordered chain of terms 
>("chain" as in "a term is a C struct that has a pointer to 
>the next term"). 
>
> You can of course easily benefit from using 1. for the indices. 
> If you have n generators, then your indices simply are sequences 
> of integers bounded by n. 
> - Multiplication is list concatenation, which is faster than for 
>   Python tuples and (if I recall correctly) even faster than operations 
>   that are based on implementing integer sequences as C "*int".  

- CombinatorialFreeModule.Element is (IIRC) implemented as dictionary, 
>   where the indices are used as keys. BoundedIntegerSequence is 
>   faster than python tuples both in hash and comparison (in particular 
>   if the tuples have common starting sequences). 
>

We definitely could do this, and I would consider having a small 
intermediate layer of converting to/from the current indices (elements of a 
free group) for backwards compatibility.

There is also a little bit of a question of do we still want CFM to be the 
base class of FreeAlgebra since we have started to decouple the pieces of 
CFM (specifically, lifting more things to the category) and FreeAlgebra 
overrides a number of things. However, that is somewhat a separate issue 
that can be tackled once we handle speeding up the basic operations. 

>
> In fact, this is what has been done in an earlier implementation of 
> path algebras. However, 2. is still faster than an implementation that 
> expresses elements as dictionaries. But I guess you don't want 
> an implementation of CombinatorialFreeModuleElementWithMonomialOrdering. 
>
> Well, we do have a number of CFM subclasses that explicitly have a total 
ordering of the indices (e.g., symmetric functions and partitions by lex 
order). However, I could see this being slower than as dicts for elements 
with a lot of terms when you have to, e.g., add two elements: you have to 
sort the two chains (which my interpretation of your description is a chain 
is a singlely linked list).

Best,
Travis

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-combinat-devel] Fwd: SageDays@ICERM

[Travis Scrimshaw]

Cross-post from Sage-devel

On Wednesday, November 15, 2017 at 6:49:13 AM UTC-6, Travis Scrimshaw wrote:
>
> Hey all,
>Gabe Feinberg, Darij Grinberg, Ben Salisbury, and I are organizing a 
> SageDays to take place at ICERM, located in Providence, RI, USA, from 
> July 23 - 27, 2018. The SageDays will focus more on combinatorics, algebra, 
> and representation theory. The workshop is open to anyone of all 
> backgrounds and skill levels and will consist of talks, demonstrations, and 
> coding sprints.
>
> Details, including the current list of speakers, can be found here:
>
> https://icerm.brown.edu/topical_workshops/tw18-1-sage/
>
> If you have any questions, feel free to contact one of the organizers (my 
> e-mail is tcscrims via gmail.com).
>
> Best,
> Travis
>
>

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-combinat-devel] Re: Free partially commutative monoid associated to a graph

[Travis Scrimshaw]

Sorry for taking so long to answer this. In short, yes, it is. The group 
version is implemented in Sage under the name right-angled Artin group (see 
groups/raag.py). That code trivially lifts up to the monoid case. Although 
a list of the letters (rather than syllables) might be better data 
structure for the elements as there are no inverses to worry about.

Best,
Travis


On Sunday, March 25, 2018 at 11:23:35 AM UTC-5, Samuel Lelievre wrote:
>
> Dear sage-combinat-devel,
>
> Someone just asked on Ask Sage whether the
> free partially commutative monoid (or trace monoid)
> associated to a graph is implemented in Sage,
> and if not, how to do it.
>
> 
> https://ask.sagemath.org/question/41756/partially-commutative-monoid-of-a-graph/
>
> Maybe someone on this list has an answer?
>
> Searching the source seems to reveal there currently
> is no implementation in Sage, as both these commands
>
> sage: search_src("trace_monoid")
> sage: search_src("partially_commutative")
>
> return nothing.
>
> But maybe it is implemented under another name?
> Or an implementation exists in a ticket somewhere?
> Or someone here can suggest how to implement it?
>
> Thanks in advance,
> Samuel
>
>
>

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-combinat-devel] Re: Categories, Parents, Elements

[Travis Scrimshaw]

>
> > Then I can think of the set of Tableaux as the parent and lists of 
> objects 
> > as elements. 
>
> You say that you "think of the *set* of Tableaux" as the parent? That 
> doesn't 
> sound promising at all. Although I don't know which notion you are using, 
> it seems likely to me that rather the *set* of all tableaux forms a 
> category, 
> which means that each individual tableau is an object in that category. 
> And "parent" is just another word for "object of a sub-cateogory of the 
> category of sets". So, if there is a category of tableaux and if each 
> tableau has elements, then a tableau is a parent and its elements are, 
> well, its elements. 
>
> This is the wrong viewpoint. The set of Tableaux should be the parent in 
the category of (enumerated?) sets since the elements are a Tableau. Most 
combinatorial objects should not be categories because the morphisms that 
people are typically interested in are bijections. A good smallish example 
to look at is the implementation of Gelfand-Tsetlin patterns (see 
src/sage/combinat/gelfand_tsetlin_patterns.py).

Do *NOT* use Posets as an example. Those are special because of the extra 
structure with the < and are naturally sets (hence parents). Posets are 
naturally a category because the morphisms have to preserve the structure.

> I have struggled to find complete examples in the 
> > combinat source code. As I understand it the key 
> > components are Parent.__init__  Element.__init__ _element_constructor_ 
> but 
> > I don't understand what these do or how they 
> > work together. 
>
> In a nutshell: 
>
> - If you implement a parent FOO, then FOO will be a subclass of 
>   sage.structure.parent.Parent, and at some point during FOO.__init__ the 
>   .__init__ methods of the base classes of FOO should of course be called. 
>   Hence, at some point, Parent.__init__(self, ...) will be called (maybe 
>   indirectly), and this is where the category of your new instance of FOO 
>   has to be declared. 
> - Similarly, if you are implementing the elements of FOO instance in a 
>   class BAR, then of course BAR will be a subclass of 
>   sage.structure.element.Element, and at some point during BAR.__init__ 
>   also Element.__init__(self, P) has to be called (maybe indirectly), 
>   where P is the instance of FOO which `self` will be element of. 
>   Nothing more specific needs to be done in BAR.__init__ regarding the 
>   category framework. 
> - You did not mention another key component: Your class FOO has to have 
>   BAR assigned to a class attribute called "Element". 
> - FOO._element_constructor_ is a method that takes some arguments and 
>   returns an element of FOO. If P is an instance of FOO, then it ought 
>   to return an instance of P.element_class. Here, P.element_class is 
>   automatically created by Sage's category framework: It is a sub-class 
>   of both P.Element (i.e., BAR) and of P.category().parent_class (which 
>   is why FOO.__init__ needs to declare which category is to be used). 
>   It is in fact not always needed to implement FOO._element_constructor_ 
>   explicitly: There is a default implementation, and having 
> `FOO.Element=BAR` 
>   may be sufficient to make it work. But if there is particular input that 
>   BAR.__init__ won't handle then FOO._element_constructor_ is where you 
>   would implement a conversion. 
>   In that sense, _element_constructor_ is less of a key component than 
>   the `Element` attribute. 
> - Also, if your element class BAR implements arithmetic operations 
>   then you should be aware that some of Python's magic arithmetic 
>   methods such as __add__ or __mul__ have default implementations in 
>   Sage's base classe (sage.rings.ring.Ring etc), and these should *not* 
>   be overridden! Instead, you may implement the corresponding single 
>   underscore method (_add_, _mul_, _lmul_). The same holds for __repr__ 
>   versus _repr_. Moreover, _add_ and _mul_ shouldn't just return instances 
>   of BAR, but of P.element_class (if P is the parent of the result of the 
>   arithmetic operation). 
> - Another key component: If there are canonical morphisms from other 
>   algebraic structures to your tableaux, then you may want to use them 
>   for automatic conversions (also known as "coercion map"). If a canonical 
>   morphism from `S` to `P` exists, then `P._coerce_map_from_(S)` should 
>   return True (it is also possible that it return the morphism to be used 
>   for automatic conversion). But be aware that this is only possible if 
>   the system of canonical morphisms is consistent: The identity map from 
>   P to P is a coercion map; there is at most one coercion map from S to 
>   P; and the composition of two coercion maps is a coercion map. 
>
> You can find a more detailed account on the category and coercion 
> framework including parents and elements in 
>
> http://doc.sagemath.org/html/en/thematic_tutorials/coercion_and_categories.html
>  
>
> For most combinatorial objects, t

[sage-combinat-devel] Re: Lie algebra representations and Crystals

[Travis Scrimshaw]

Hi Nicolas,

>
> I am doing computations in a Lie algebra representation V; actually a 
> pretty simple one, though huge (in case this is relevant, V is a 
> subspace of the ring of polynomials in r sets of n variables, under 
> the action of gl_r. The nice feature is that weight spaces are 
> directly given by the multigrading, and the e and f operators are 
> given by polarization). 
>
> Question I: assume that I have a highest weight vector v for a simple 
> submodule of V. Consider the crystal of tableaux of the same weight. 
> Take a set S of tableaux T; for each of them, pick a string of e 
> crystal operators going from the highest weight tableau to T. 
>
> Can I by any chance assume that, if the corresponding strings of e 
> operators in gl_r are applied on v, I get linearly independent 
> elements in V? 
>

Yes you can (assuming you have 1 vector for each path in the crystal). It 
is essentially by construction from the Verma module with the PBW basis but 
thinking of the vectors f_* v. Although I think the good way to do this is 
by the "adapted strings" method that de Graaf attributes to Littelmann in 
his "Constructing canonical bases of quantized enveloping algebras". I am 
pretty sure you can also tease this out directly from the definition of the 
Kashiwara operators.

>
> Question II: assume that I have a weight space V_\lambda; I can easily 
> compute the subspace HV_\lambda of highest weight vectors in V_\lambda 
> by taking the joint kernel of the e operators. But for my computation 
> I would need to instead have a *projection* from V_\lambda to 
> HV_\lambda. Is there a way to construct such a projection, e.g. in 
> term of the operators of the Lie algebra? 
>
>
So if you have a polarization and a basis for your submodule, you can use 
that to do your projection. In particular, the crystal basis is the set b 
\in V such that (b, b')_0 = \delta_{m,m'}, where m is the index of the 
element b. However, that assumes you are working with coefficients in the 
0-regular (functions f/g such that g(0) \neq 0) sublattice.

The more brute-force way of doing this is to construct a basis for 
HV_{\lambda} using the gl_r action and extend that to V_{\lambda} using a 
Gram-Schmidt-type approach to get a full basis of V_{\lambda} that 
naturally has the projection, then conjugating that natural projection 
matrix with the corresponding COB matrix to obtain your projection.

(I've done similar computations to compute highest weight elements, and I 
found that stacking the e matrices and taking the kernel of that to be much 
faster than taking the intersections of the kernels in Sage.)

>
> In general, refs about this type of computations in Lie algebras are 
> very welcome ... 
>
> de Graaf is the person who has done the most with these types of 
computations (a number of which are implemented in GAP4).

http://www.science.unitn.it/~degraaf/pub.html
This paper of his 

 
is probably a good starting point as well.

Best,
Travis


-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-combinat-devel] Re: SkewTableaux

[Travis Scrimshaw]

On Friday, June 1, 2018 at 7:25:21 PM UTC+10, Bruce wrote:
>
> I am confused about the interface between SkewTableaux and Tableaux.
> I suspect this is something people are aware of.
>
> The points I have come across (and I doubt these are the only ones) are:
>
> A SkewTableau can be created from a chain of partitions using the keyword 
> chain.
> This does not work for Tableau. There is a work around:
> given a chain of partitions which starts with the empty partition,
> create the skew tableau using the chain keyword,
> convert to a list,
> use this to construct a tableau.
>

Most likely because nobody implemented it. Please add.

>
> Evacuation and promotion are not defined for skew tableaux.
> Is this because the definition does not make sense or because
> no-one has yet included them?
>

IDK. My initial thought is that these are well-defined, but I don't know if 
you get the usual properties for skew tableaux (and hence, are 
"uninteresting"). Yet, it is most likely the latter case.

>
> Mathematically, a tableau is a skew tableau with empty inner shape.
> Many (most?) methods make sense for skew tableaux.
> Ideally, these methods would be defined for skew tableaux
> and made available to straight tableaux. I don't know the
> appropriate mechanism for doing this in sage but I expect
> people have ideas or even plans on this.
>

I believe part of the reason for this is that it takes a bit of extra 
processing power (not to mention code) to check for the None's that can 
appear in a skew tableau. Plus the general class hierarchy for the (skew) 
tableau code needs some cleanup (there is at least one stalled ticket 
toward this effect). 

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-combinat-devel] Re: Discreture library: iterate through combinations, permutations, partitions...

[Travis Scrimshaw]

It definitely could help with some things. However, I am a bit turned off 
on using it considering statements about comparing a highly optimized 
special purpose library with SageMath:

This comparison isn't very fair (C++ vs python). On the same system, 
> iterating over all (24 choose 12) combinations, sage takes 12.2 seconds. 
> Discreture takes approximately 0.005 seconds. No point in graphing that.
>

Also, that is somewhat of a poor choice to do a benchmark against as that 
is a recursive python iteration as opposed to, say, Partitions. A proper 
benchmark instead of immediate dismissal and needless editorial would have 
been much better (and useful).

On a more technical aspect, the boost dependency might be a problem. We 
have a slimmed down boost, but if it requires the full boost, then that 
might be a problem. I'm also not sure how Sage will work with a header only 
library.

Best,
Travis


On Monday, August 6, 2018 at 9:03:29 PM UTC+10, Samuel Lelievre wrote:
>
> Dear sage-combinat-devel,
>
> Discreture is a C++ library for iterating through various combinatorial
> structures such as combinations, permutations, partitions, etc.
>
> https://github.com/mraggi/discreture
>
> Could it bring speedups to any of Sage's combinatorics?
>
> Kind regards,
> Samuel
>

-- 
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...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-combinat-devel] Re: fast vector partitions algorithm

[Travis Scrimshaw]

Hi Denis,
   That is great that it can have a faster implementation. Do you have the 
code available for us somewhere? Some thing to also note is that 
VectorPartitions creates a Sage Element instance instead of a simple Pyhton 
list, which has extra overhead. However, this should not account for most 
of the difference between the two timings I believe. Dealing with the min 
should be straight-forward; worst case is we just fallback to the current 
implementation. We might even be able to get it faster with Cythonizing it.

As Simon said, I would just insert it directly into the Sage source code.

Best,
Travis


On Monday, February 10, 2020 at 9:34:40 PM UTC+10, Denis Sunko wrote:
>
> I have translated the Haskell code for vector partitions by M. C. Er, The 
> Computer Journal, Vol. 31, 1988, 283-284, into Python (2 or 3, stand-alone 
> file with 60 lines total).
>
> The code works significantly faster than the Sage implementation:
>
> ┌┐
> │ SageMath version 9.0, Release Date: 2020-01-01 │
> │ Using Python 3.7.3. Type "help()" for help.│
> └┘
> sage: import vpartitions
> sage: %time myvparts=vpartitions.vPartitionso([6,6,6])
> CPU times: user 9.13 s, sys: 89.8 ms, total: 9.22 s
> Wall time: 9.22 s
> sage: %time sagevparts=list(VectorPartitions([6,6,6]))
> CPU times: user 2min 10s, sys: 177 ms, total: 2min 10s
> Wall time: 2min 10s
> sage: myvparts[::-1]==sagevparts
> True
>
> If someone would take over the job of contributing this code to Sage, I 
> would be glad to help. There are a few caveats:
>
> 1) the code is recursive;
> 2) there is no "min" option like in the Sage implementation.
>
> I do not know how difficult (or necessary) it would be to address these 
> points.
>
> Of course, anyone can take it up straight from Er's paper instead, I won't 
> be jealous:)
>
> Cheers,
>
> Denis
>
>

-- 
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...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-combinat-devel/45509e06-9672-47c8-be92-7a1a52d36287%40googlegroups.com.

[sage-combinat-devel] Re: fast vector partitions algorithm

[Travis Scrimshaw]

Thanks to everybody for the friendly replies.
>
> I could paste the code right here, is that the proper way to do it? How is 
> the license transferred to Sage?
>

The way to submit code is to push a git branch to our trac server and then 
update the ticket to include that branch name under the branch field. For 
more, see

http://doc.sagemath.org/html/en/developer/manual_git.html


> I have a trac account because I once contributed a small bugfix 
>  but nothing happened with it, so 
> it seems like i don't understand how the system works.
>

You need someone to see the ticket, and from the title and status, it was 
not clear that there is a fix proposed. Your proposed fix should be turned 
into a git branch as well, and you should also add a doctest showing it is 
fixed (specifically, the example in the description).

>
> I read some of the developer's guide but it all seemed rather 
> intimidating, especially for a small change. I have been programming as 
> part of research, but only my own code, never collaborative projects.
>
> I will repost to sage-devel. Any further advice is welcome.
>

I don't see the need to do that here since you have gotten some attention 
for your proposal. However, future posts might be better relegated to 
sage-devel as this is not as active of a mailing list as it used to be. 
Feel free to ask here or on sage-devel (maybe sage-support?) or on the 
tickets if you have any questions. You can cc me "tscrim" on them as well.

Best,
Travis

-- 
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...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-combinat-devel/d9eb60de-b00a-43a5-a84d-7a51dbcaaf59%40googlegroups.com.

[sage-combinat-devel] Re: fast vector partitions algorithm

[Travis Scrimshaw]

>
>> I have opened a trac ticket  
>> now. Unfortunately something weird is happening with my local git branch. I 
>> have copied a file fast_vector_partitions.py with all the source code (it 
>> works in ordinary Python with 'import fast_vector_partitions') and 
>> recompiled Sage under this branch, which I call fast_vector_partitions (the 
>> head is local, no connection to the trac server yet). 
>>
>> Problem: after rebuilding Sage under this branch I cannot use the 
>> functions in the file under the sage prompt - the function name is 
>> "undefined". I did both ./sage -br and make, several times.
>>
>> I can see that something happened in the build because the file has 
>> migrated from src/sage (where I put it) to src/build and local/lib, and 
>> a .pyc file has appeared:
>>
>> $ find . -name "*fast_vector*"
>> ./src/build/lib.linux-x86_64-3.7/sage/combinat/fast_vector_partitions.py
>> ./src/sage/combinat/fast_vector_partitions.py
>>
>> ./local/lib/python3.7/site-packages/sage/combinat/fast_vector_partitions.py
>>
>> ./local/lib/python3.7/site-packages/sage/combinat/__pycache__/fast_vector_partitions.cpython-37.pyc
>> ./.git/logs/refs/heads/fast_vector_partitions
>> ./.git/refs/heads/fast_vector_partitions
>>
>> I hesitate to connect this branch with the trac server before figuring 
>> out what is going on. In any case I think I should try the build locally 
>> first.
>>
>
> there is nothing wrong with pushing a non-working branch somewhere.
> This way it's very easy to see what's going wrong there.
> (I guess it's something to do with importing things)
>

Also linking it to the ticket by filling out the branch field there.

Best,
Travis

-- 
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...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-combinat-devel/de04b8ee-a78f-44d3-b087-f37c61286da4%40googlegroups.com.

[sage-combinat-devel] Re: dot2tex, combinat

[Travis Scrimshaw]

Hey,
   Here's the results of the tests I have done and my interpretations.
Calling view() (from the notebook) calls the underlying OS's latex
compiler, and then I believe the notebook displays the resulting pdf
in the output window. So by doing ctrl-C twice to get to the shell,
then running "sudo yum install dot2tex" (the root password is "sage"),
and finally running "./sage -i dot2tex" . This installs dot2tex on the
underlying Fedora OS, then in sage specifically. From here I was able
to generate the latex output in the notebook without errors on the
first time, and you can copy this over to your external latex compiler
and pdf viewer.

   I copied the latest version of TikZ / PGF (using a shared folder)
to the VM and installed it. I was able to compile the .tex file using
the VM's latex compiler and view the output .pdf from my host OS
(Windows Vista) in the shared folder, but I could not get it to
display in the notebook. (See http://wiki.sagemath.org/SageAppliance
on the shared folders.) The error I got was `Unknown environment
"tikzpicture"` and I also can compile the pdf on my host OS, so
somehow there is a disconnect between the notebook and the VM's OS.

   Also, as for the mouse disappearing, that is when the mouse gets
"caught" by the VM window and if you're running Virtual box, the
default key to release the mouse is the *right* control (ctrl) key.
The reason why you don't see the mouse is because the VM OS is a text-
only environment, and with this, I believe you cannot easily open an
external viewer from the VM.

Best,
Travis

-- 
You received this message because you are subscribed to the Google Groups 
"sage-combinat-devel" group.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
To unsubscribe from this group, send email to 
sage-combinat-devel+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sage-combinat-devel?hl=en.

[sage-combinat-devel] Re: dot2tex, combinat

[Travis Scrimshaw]

John,
   I tried using it and I got the following error:

Error: convert (from the ImageMagick suite) does not
appear to be installed. Displaying PDFLaTeX output
requires this program, so please install and try again.

Go to http://www.imagemagick.org to download it.
Latex error

   This is likely because the pdf output from sage depends upon the
tikz package. Additionally the tikzpicture environment requires the
tikz package so I doubt the pdf would be compiled despite the above
error.

Nicolas,
   The first issue should be easy enough to resolve and just make sure
the base image for the Sage notebook download has the packages already
installed.

For the second issue, do you know how the notebook communicates with
the Sage in the VM and vice versa, or at least have some idea on where
I could find the code? Also, could you tell me how Sage currently
produces images/latex output to the notebook?

I like your idea on sending the PDF directly the web browser, and I'm
thinking we should have it as an option in the view() command since it
is overkill in most cases and I don't know what kind of difficulties
with pop-up blockers we might encounter. Also, to me this is somewhat
of a hack solution unless we could somehow embed a pdf viewer in the
notebook, but I doubt this is possible since I suspect the notebook
runs through HTML with a C/S interface with the VM. Anyways, I'll
start a discussion on the sage-devel/trac and take a look at possibly
cleaning up the patch.

Best,
Travis

-- 
You received this message because you are subscribed to the Google Groups 
"sage-combinat-devel" group.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
To unsubscribe from this group, send email to 
sage-combinat-devel+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sage-combinat-devel?hl=en.

[sage-combinat-devel] Data structure design pattern (for Cartan types)

[Travis Scrimshaw]

Hey everyone,
   There are multiple classes in Sage right now that are essentially
the same data, in particular, CartanType, DynkinDiagram, and (the
function) cartan_matrix(). So what I am proposing is a new design
pattern that is essentially the http://en.wikipedia.org/wiki/
State_pattern">state design pattern which would work as follows:

class RepresentationContract:
- Set of common functions to each object
- List of functions all concrete representations will implement

class RepresentationError:
- Thrown when we cannot convert into a particular representation

class ObjectHolder:
- Dictionary (or individual members) of all created
representations
def get_representation(rep_name): (or individual functions to get
specific representations)
- All functions that are common to all representations (such as
iterating through all objects) would choose the best representation to
use.

The concept is to tell the user that this is essentially the same data
mathematically and providing a common interface when we do not care
about the underlying representation or we need to go between different
representations of the same object (to help avoid cluttering the
namespace).

Specifically I would like to create the following class:

# This is the holder class
class CartanDatum(UniqueRepresentation):
def __init__(self, **options):
self._reps = { } # Make sure it is initalized
# handle the options

def cartan_matrix(self):
if not self._reps.has_key("cartan_matrix"):
# Create Cartan matrix
return self._reps["cartan_matrix"]

def cartan_type(self):
if self._reps.has_key("cartan_type"):
return self._reps["cartan_type"]
throw RepresentationError("Cannot generate Cartan Type")

# And other accessor/common methods

In this instance, it would not remove or change any existing code.

I'm also thinking we could also make this more flexible by adding a
static function called add_rep() to the holder class which takes a
class which is a subclass of RepContract and maintaining a static list
of classes in the holder along with methods in the contract to
interconvert between some base representation.

What are you thoughts on this?

Thank you,
Travis Scrimshaw

-- 
You received this message because you are subscribed to the Google Groups 
"sage-combinat-devel" group.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
To unsubscribe from this group, send email to 
sage-combinat-devel+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sage-combinat-devel?hl=en.

[sage-combinat-devel] Re: Data structure design pattern (for Cartan types)

[Travis Scrimshaw]

Hey,

   Originally I was thinking the global namespace, but to avoid
breaking code (and apparently to conform more to python coding
practices), I am now thinking for this case we expose only CartanDatum
to the user and have static references to the subsequent classes
(accessed as attributes). For example to access directly the
CartanType class, one would run

CartanDatum.CartanType(['A', 2])

I was thinking of using this as an initial sample of a design pattern
to implement in math objects with lots of different representations
such as the partitions or matrices (such as if they are sparse or
not).

   Right now I just cached the results from the function
cartan_matrix() which seemed like the natural place to do so since we
only need a singleton (a UniqueRepresentation in sage) of each matrix
for each Cartan type. This actually netted a speed increase over
caching CartanType.cartan_matrix() and adding an attribute in
RiggedConfigurations (I removed in influence of KleberTree from my
speed tests by creating it beforehand).

> By the way: at this point, cartan matrices in Sage are plain matrices;
> in particular, they are indexed by 0,1,..., and not by the index set
> of the dynkin diagram. So it is a lucky coincidence that, for affine
> type (whose index set is 0,...,n), M[i,j] returns the correct result.
> It would be safer to use instead the dynkin diagram.
>
> (And someday someone should implement matrices indexed by anything,
> and upgrade cartan matrices accordingly).

I concur with this, but I think we should carry this one step further
and have vectors spaces whose basis is indexed by arbitrary lists so
the matrices can act in a natural fashion.

Best,
Travis

-- 
You received this message because you are subscribed to the Google Groups 
"sage-combinat-devel" group.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
To unsubscribe from this group, send email to 
sage-combinat-devel+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sage-combinat-devel?hl=en.