On Wed, Apr 06, 2011 at 04:46:05PM -0700, Daniel Bump wrote:
> I saw your reviewer patch for #7922 (thanks).
>
> There were a couple of further minor revisions
> which are in the patch
>
> trac_7922_alpha3-changes.patch
>
> that I put in the combinat queue. The patch:
>
> trac_7922-rebased-4.7.
Hi Nicolas,
I saw your reviewer patch for #7922 (thanks).
There were a couple of further minor revisions
which are in the patch
trac_7922_alpha3-changes.patch
that I put in the combinat queue. The patch:
trac_7922-rebased-4.7.alpha3.patch
that is now on the trac server is the sum of
the thre
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
On Fri, Feb 25, 2011 at 06:12:15PM +0100, Nicolas M. Thiery wrote:
> - What would be an efficient implementation of hashing for free
>module elements? The one you implemented in AmbientSpace can
>be 10 times faster than the default one provided by SageObject and
>using repr. So it wo
Hi Dan,
I have just been through your #7922 patches, and put a reviewers patch
in the Sage-Combinat queue:
trac_7922-review-nt.patch
Altogether it looks good. I did a few changes, and also added a series
of comments and suggestions. Please check them out, and decide which
ones yo
> - Is it reasonnable that hash is called 4 000 000 times in your
>example? Are there huge elements being manipulated?
No, I don't think that is reasonable. So there must be something
fishy going on.
The character of A7 (SL(8)) in question has 792 weights with nonzero
coefficient. This is n
Hi Dan!
On Thu, Feb 10, 2011 at 09:35:08AM -0800, Daniel Bump wrote:
> 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 Code
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
15 matches
Mail list logo
