[sage-combinat-devel] Re: Pickle jar
Salut, I worked recently on the pickle jar #10354. It needs review. If we are many changing it at the same time, I guess it may cause trouble... If it's the case, let's talk and have a good strategy... http://trac.sagemath.org/sage_trac/ticket/10354 Since it is the first time I am changing the pickle jar, I wrote on ticket all what I understood about how to do such a modification. It might be usefull if one wants to improve the documentation about pickle jar (?). Cheers, Sébastien 2011/2/10 Nicolas M. Thiery : > On Wed, Feb 09, 2011 at 04:51:14AM -0800, Anne Schilling wrote: >> For #8911 the new pickle jar was just attached. So I added this file >> to #10632. Probably you can do the same for #7922 (but then the tickets >> might not commute if both change the pickles). > > Yeah, that pickle jar procedure is not perfect yet. I have just > created a ticket with a suggestion for improving it: > > http://trac.sagemath.org/sage_trac/ticket/10768 > > 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-days" group. > To post to this group, send email to sage-combinat-d...@googlegroups.com. > To unsubscribe from this group, send email to > sage-combinat-days+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/sage-combinat-days?hl=en. > > -- 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] # 10744
Here are some comments on #10744.
Very nice!
I do have some comments.
sage: A2=WeylCharacterRing("A2",style="coroots")
sage: a2=WeightRing(A2)
sage: rp=a2(A2(2,1))
sage: rp.plot()
Frequently one will want to call this for the character of
a representation. It would be good if one could:
A2(2,1).plot()
without having to create the weight ring. Of course some
times one might also want to be able to call it on an
element of the weight ring that is not W invariant (and
which could therefore not be coerced into the WeylCharacterRing).
I guess to accomplish this one could have to move some of the code
into an auxiliary method of the WeylCharacterRing that would be
called by plot methods of both the Weyl character ring and the
weight ring.
The plot that I like best is:
rp.plot(weight_lattice=false)
So maybe the weight lattice could be suppressed by default.
Here is a more serious criticism.
A grid is shown whose vertices are the weights.
But this grid is not invariant under the action of the Weyl group!
Although the grid that you've shown does pass through the weight
lattice, it is sort of unnatural for this reason. The grid
you've shown is one whose fundamental domain is the
parallelogram spanned by the fundamental weights, but since it is
not W invariant I think it is bad to use this grid.
A more natural and useful grid would be the one that passes through
the hyperplanes where the coroots take integer values. This is the
Stieffel diagram for the dual weight root system. Like the
grid you showed it is a grid whose vertices are the weights, but
unlike the one your code displays it is W-invariant.
It would also be good to be able to see the hyperplanes where the
roots take integer values. This is the Stieffel diagram. Then
you can see pictures of the fundamental alcoves.
You can see Stieffel diagrams on page 227 of Brocker and Tom
Dieck's book Representations of Compact Lie Groups. This happens to
be one that is displayed by Google Books. (Google search for
Stieffel Diagram.)
It would be good to be able to see these grids, but not by default,
since I think they make things too cluttered. Since I'm proposing
two optional methods showing the fundamental alcoves and dual
alcoves, maybe the name should be changed.
It seems to me (in the A2 case) that the root arrows are perfectly
placed, but the pink arrows corresponding to the fundamental
weights fall short of where they should. Especially the second
fundamental weight which points straight up. And maybe the pink
arrows are too thick.
It seems to me that the pictures are wider than tall. This is
particularly obvious for B2 and C2 since the lattices are
supposedly square.
I looked at the B2,C2 and G2 pictures of irreducible
characters. For G2 the weight multiplicities get large fast, and
I'm not sure whether some tuning of the default dot size might be
profitable, at least for G2. One idea would be that the dot size
could be proportional to the square root of the multiplicity.
(I'm not sure how well this would work, just an idea.)
Dan
--
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: Pickle jar
Oops, I am so sorry. This mail was only meant to be sent to sage-devel and sage-combinat-devel. Please moderate if still at all possible. On Thu, Feb 10, 2011 at 06:44:11PM +0100, Nicolas M. Thiery wrote: > On Wed, Feb 09, 2011 at 04:51:14AM -0800, Anne Schilling wrote: > > For #8911 the new pickle jar was just attached. So I added this file > > to #10632. Probably you can do the same for #7922 (but then the tickets > > might not commute if both change the pickles). > > Yeah, that pickle jar procedure is not perfect yet. I have just > created a ticket with a suggestion for improving it: > > http://trac.sagemath.org/sage_trac/ticket/10768 > > 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 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] Pickle jar
On Wed, Feb 09, 2011 at 04:51:14AM -0800, Anne Schilling wrote: > For #8911 the new pickle jar was just attached. So I added this file > to #10632. Probably you can do the same for #7922 (but then the tickets > might not commute if both change the pickles). Yeah, that pickle jar procedure is not perfect yet. I have just created a ticket with a suggestion for improving it: http://trac.sagemath.org/sage_trac/ticket/10768 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 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] #7922 timing issues
I am returning to the question of timing issues with #7922.
I recall that for a variety of branching rules, I ran tests
with and without the test, and obtained the following
results:
Old Code48 seconds
New Code25 seconds
Old Code, cache=true18 seconds
This is copied from the trac ticket.
With the old code, there is an option to cache results of calculations,
such as multipliciations. The caching is implemented by dictionaries, and
@cached_method is not used. After #7922, caching is done by default,
A question is therefore whether #8611 improved these results. I can
investigate this, but I am more concerned about something else,
unrelated to caching.
Consider the following task:
sage: A2=WeylCharacterRing("A2",style="coroots")
sage: A7=WeylCharacterRing("A7",style="coroots")
sage: s = A7.fundamental_weights()[1]
sage: ad=A2(1,1)
sage: A7(5*s).branch(A2,rule=branching_rule_from_plethysm(ad,"A7"))
A2(0,0) + A2(0,3) + 2*A2(1,1) + A2(3,0) + A2(1,4) + 2*A2(2,2) + A2(4,1) +
A2(2,5) + 2*A2(3,3) + A2(5,2) + A2(4,4) + A2(5,5)
This computes the fifth symmetric power of the 8-dimensional
adjoint representation of GL(3), decomposing it into irreducibles.
With the old code, caching has no effect on the timing of this:
on one machine, it takes about 8.8 seconds.
However after applying #7922, the same task takes about 31
seconds on the same hardware.
This seems unacceptable to me. I think we need to try to understand
the reason that this is slow before #7922 can be considered.
Dan
--
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.
Re: [sage-combinat-devel] Re: tickets 10632 and 10485
On Wed, Feb 09, 2011 at 02:59:56PM -0800, Anne Schilling wrote: > >That being said, this could advocate for keeping CrystalOfTableaux as > >a class (using the classcall trick as we had discussed) in order to > >maintain backward compatibility on pickles (beside the other > >advantages). Anne: I can make a quick patch over yours tomorrow doing > >just that if you want. > > If you like. What are the other advantages? Single entry point. Isn't it currently a pain that one creates a partition using: sage: p = Partition([3,2,1]) and test if `p` is a partition with: sage: isinstance(p, sage.combinat.partition.Partition_class) ? The same holds here: a single name to remember, a single gadget to export, a single gadget for all usage. > If you are making a patch anyway, could you please also fix the 0.5 > to 1/2 that you did not like and Integer to int. (I remember that I > first tried with int, but it did not work for me, but then I had not > used Dan's trick). Done and pushed! I did a couple improvements here and there (mostly doc). Please review, and if things are ok, either fold or post on trac. 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 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: [sage-devel] sage thoughts
Hi Doug, Welcome to the Sage community! On Wed, Feb 09, 2011 at 01:02:10PM +0800, D. S. McNeil wrote: > (2) No kwarg constraints in Partitions/Compositions should be mutually > exclusive. (I think there's a ticket for this but I can't find it > now.) > > Partitions(15,length=5, parts_in=[1,3,4]) doesn't work, so you have to > do an explicit filter. Optimizing it is a separate issue, but when > there's a trivial way to implement the functionality (simply test that > partitions satisfy the specified criteria before yielding them, in > cases where we don't currently embed the constraints in the > construction process itself), then ISTM we should do so now rather > than wait for a more efficient implementation to appear. > Functionality+speed > functionality, but functionality >>> no > functionality. Annoying, huh? This has bothered us ever since IntegersListLex was first implemented in MuPAD 9 years ago :-) In principle one of the goals of the upcoming Sage Days in Acadia in May is to reimplement IntegersListLex (http://trac.sagemath.org/sage_trac/ticket/6538). I can't guarantee that it will actually happen though. Volunteers are welcome to implement a temporary fix. However one should be careful: the kwarg options are *not* mutually exclusive as long as they are consistent (for some loose definition of consistent), and this feature is used in many places. So one should be careful not to slow things down in those situations. > Currently, partitions_restricted's docstring says not to use it but to > use RestrictedPartitions instead, which in turn says not to use > RestrictedPartitions but to use Partitions with the "parts_in" > keyword, which in its turn doesn't work. Specific examples welcome! Best, 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 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.
