The new crystal patch is now on trac 8154 and needs review!
Any volunteers?
Anne
--
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-de...@googlegroups.com.
To unsubscribe from this group, s
Good morning, Nicolas!
I finalized the new crystal patches (affine-E-as.patch,
affine-E-revised-as.patch). I left the facade = True option
for direct sums when no crystal is repeated. Also, HighestWeightCrystals
now only takes one weight as input. In the process I removed the
__class__ method whi
Hello!
On Mon, Feb 01, 2010 at 09:24:05AM -0800, Anne Schilling wrote:
> You say this since the elements in the direct sum will have different
> parents depending in which B_i they sit in? I guess turning
> facade = False should fix this problem.
Indeed. But there will be a price to pay:
Hello Nicolas,
Hmm, I would say not quite. But we can discuss this later on.
You say this since the elements in the direct sum will have different
parents depending in which B_i they sit in? I guess turning
facade = False should fix this problem.
Some other questions I had last night which I
Good morning Anne!
On Mon, Feb 01, 2010 at 07:48:07AM -0800, Anne Schilling wrote:
> >Just one thing though: with facade = True, the elements of the crystal
> >won't know that their parent is the direct sum crystal. This may, or
> >may not, be a problem in practice. It's a good occasion to
Nicolas M. Thiery wrote:
On Sun, Jan 31, 2010 at 10:28:11PM -0800, Anne Schilling wrote:
I have implemented the direct sum of crystals in the patch crystal-hw-as.patch.
The good news is that in the case when there are no multiplicities in the B_i,
one can use the options keepkey = False, facade
On Sun, Jan 31, 2010 at 10:28:11PM -0800, Anne Schilling wrote:
> I have implemented the direct sum of crystals in the patch
> crystal-hw-as.patch.
>
> The good news is that in the case when there are no multiplicities in the B_i,
> one can use the options keepkey = False, facade = True
> and the
Hi Niolcas,
On Sun, Jan 31, 2010 at 01:01:44PM -0800, Anne Schilling wrote:
Should
direct_sum_of_crystals
be a method similar to
TensorProductOfCrystals?
Then the input would be a list of crystals (B_1,...,B_n) whose direct sum one
takes.
I suppose the elements would then be stored as tuple
tu
On Sun, Jan 31, 2010 at 02:27:50PM -0800, Anne Schilling wrote:
> >>Should direct_sum_of_crystals be a method similar to
> >>TensorProductOfCrystals?
> >>Then the input would be a list of crystals (B_1,...,B_n) whose direct sum
> >>one takes.
> >>I suppose the elements would then be stored as tu
Should
direct_sum_of_crystals
be a method similar to
TensorProductOfCrystals?
Then the input would be a list of crystals (B_1,...,B_n) whose direct sum one
takes.
I suppose the elements would then be stored as tuple
tuple(b,i)
where b \in B_i.
Yes. And you can inherit from DisjointUnionEnumerat
On Sun, Jan 31, 2010 at 01:01:44PM -0800, Anne Schilling wrote:
> Should
> direct_sum_of_crystals
> be a method similar to
> TensorProductOfCrystals?
> Then the input would be a list of crystals (B_1,...,B_n) whose direct sum one
> takes.
> I suppose the elements would then be stored as tuple
> tu
Mathematically speaking, do we really want to accept:
HighestWeightCrystal(dominant_weights = (...))?
That is, do we want to consider a disconnected crystal as a highest
weight crystal, if all its connected components are highest weight?
I am not so sure. Notes:
- This feature is not c
On Fri, Jan 29, 2010 at 06:54:52PM -0800, Anne Schilling wrote:
> > By the way, I just realized that: isn't the cartan type information
> > redundant? Shouldn't HighestWeightCrystal just take a weight as input?
>
> Ok, in principle I agree.
>
> From the programming point of view, how can this be
Hi Nicolas,
Here is the description of affine-E-nt.patch. Feel free to fold. If I
get to work more on this, I'll create a new patch.
- Added UniqueRepresentation to the type E highest weight crystals
- Factored out command abstract superclass for E6 and E7
- Still failing tests in kirillov_r
Hi Anne,
On Wed, Jan 27, 2010 at 02:59:41AM +0100, Nicolas M. Thiery wrote:
>- One that sounds more tricky (failing assertion in
> highest_weight_dict in the construction of the KR_type_E6_order2
> crystal)
By the way: in case there is a doubt that my changes may have broken
Hi!
On Tue, Jan 26, 2010 at 02:14:27PM +0100, Nicolas M. Thiery wrote:
> On Tue, Jan 26, 2010 at 12:06:40AM -0800, Anne Schilling wrote:
> > Please go ahead. Otherwise I'll look at this later this week.
>
> Ok. I'll do that probably tonight.
Here is the description of affine-E-nt.patch.
On Tue, Jan 26, 2010 at 02:08:49PM -0800, Anne Schilling wrote:
> KirillovReshetikhinCrystal only dispenses to the nonconjectural
> implementation KR_type_E6. The equivalent (but conjectural) code
> KR_type_E6_order2 is not referred to elsewhere. Is this acceptable?
That definitely does the job. T
Nicolas M. Thiery wrote:
On Tue, Jan 26, 2010 at 12:06:40AM -0800, Anne Schilling wrote:
Please go ahead. Otherwise I'll look at this later this week.
Ok. I'll do that probably tonight.
How can it be private if it is already on the sage-combinat server :-) ?
Well, the sage-combinat server
On Tue, Jan 26, 2010 at 12:06:40AM -0800, Anne Schilling wrote:
> Please go ahead. Otherwise I'll look at this later this week.
Ok. I'll do that probably tonight.
> How can it be private if it is already on the sage-combinat server :-) ?
Well, the sage-combinat server is not that trivial to use
Hi Nicolas,
I rebased the later crystal patches and removed the guard.
Currently a lot of tests in combinat/crystals/highest_weight_crystals.py
fail. I need to investigate why this is so (I am sure they passed when I
submitted
the patch a long time ago).
I just had a look. It's just that Cry
Nicolas M. Thiery wrote:
On Sat, Jan 23, 2010 at 06:14:59PM -0800, Anne Schilling wrote:
Thank you for the further cleanup. One immediate problem is that it causes the
patch affine-E-as.patch to fail.
Ooops, I should have checked that. I am adding a +crystal guard on my
patch until the other p
On Sat, Jan 23, 2010 at 06:14:59PM -0800, Anne Schilling wrote:
> Thank you for the further cleanup. One immediate problem is that it causes the
> patch affine-E-as.patch to fail.
Ooops, I should have checked that. I am adding a +crystal guard on my
patch until the other patches are rebased. I won
Dear Nicolas,
Thank you for the further cleanup. One immediate problem is that it causes the
patch affine-E-as.patch to fail.
Also in sage-4.3.1 the view command is broken
C = CrystalOfLetters(['A',2])
view(C, viewer = 'pdf', tightpage = True)
I assume this has to do with the broken graphiz pat
23 matches
Mail list logo
