On Mon, Mar 21, 2011 at 07:58:59PM -0700, Daniel Bump wrote:
> > I just pushed my changes on the Sage-Combinat queue. The code uses
> > standard coercion now.
>
> Thanks! At the moment, I can say that after your patch,
> the code seems to be about the same speed as before,
> which is good.
In th
> I just pushed my changes on the Sage-Combinat queue. The code uses
> standard coercion now.
Thanks! At the moment, I can say that after your patch,
the code seems to be about the same speed as before,
which is good.
> I won't touch the thing tomorrow, so feel free to fold all the 7922
> patche
On Tue, Mar 22, 2011 at 01:21:36AM +0100, Nicolas M. Thiery wrote:
> I just pushed my changes on the Sage-Combinat queue. The code uses
> standard coercion now. In the process, I have factored out a couple
> functions to the ambient space (from_vector_notation, the coerce_E6
> and friends). It's no
On Mon, Mar 21, 2011 at 10:35:55PM +0100, Nicolas M. Thiery wrote:
> On Sat, Mar 19, 2011 at 07:37:25AM -0700, Daniel Bump wrote:
> > Well, what you are suggesting is a little tricky. Two
> > rings will be created at the same time, and the
> > multiplication will be implemented by coercing from
> >
On Sat, Mar 19, 2011 at 07:37:25AM -0700, Daniel Bump wrote:
> Well, what you are suggesting is a little tricky. Two
> rings will be created at the same time, and the
> multiplication will be implemented by coercing from
> the WeylCharacterRing to the WeightRing, multiplying,
> and coercing back.
> Can you elaborate? Is there a compelling technical reason?
Well, what you are suggesting is a little tricky. Two
rings will be created at the same time, and the
multiplication will be implemented by coercing from
the WeylCharacterRing to the WeightRing, multiplying,
and coercing back. And I see
Hi Dan,
Sorry for letting this slip down my mailbox ...
Florent: please see the intersphinx question below.
On Mon, Mar 07, 2011 at 06:48:56AM -0800, Daniel Bump wrote:
> As I noted earlier, the timing issue is apparently fixed by
> making _weight_multiplicities a cached method, and the
Here is the status of #7922.
As I noted earlier, the timing issue is apparently fixed by
making _weight_multiplicities a cached method, and the
caching can be removed from product_on_basis.
Nicolas has a patch called trac_7922-review-nt.patch.
Some of his comments can be implemented, others not
