On Wed, Feb 23, 2011 at 06:39:03PM -0500, Christian Stump wrote:
> After pulling again, you should get the problem I had:
>
> sage: ct = CartanType(['A',3])
> sage: L = ct.root_system().root_lattice()
> sage: L.simple_root(1)
> alpha[1]
> sage: L.simple_root(1).associated_coroot()
> ...
> -> 1777 assert domain.base_ring() == codomain.base_ring()
> ...
> AssertionError
>
> The reason for the error is as described.
Ok, thanks, I see the issue now. There are several parts to it:
(a) The name "to_coroot_lattice_morphism" is misleading since the
results lives in the coroot space.
(b) The implementation is broken, since one currently can't define a
diagonal morphism from a K-free-module to a L-free-module when K
is a strict subring of L.
Hmm. Nothing bad, but some though should be put in to formalize a bit
more the specifications. That would be a bit tedious by e-mail since
there are some mathematical technicalities. So if you have a quick
workaround for your current needs, I suggest that we have a brainstorm
about this next May. For the record, here are some questions to
discuss then.
Let L be a realization of the root lattice:
- Where should L.coroots() live?
- Where should L.coweights() live? How to handle the non finite cases
(the Cartan matrix being singular, one may not be able to define
the dual basis depending on how the roots are realized)?
- What are the exact specs we want to have for the morphism above (nu
in the litterature)
> > The conceptual way (and thus independent on the realization at hand)
> > is to take the scalar product of beta with the simple coweight
> > corresponding to alpha. This should (be made to) work; however there
> > are things to straighten out around scalar products and coweights ...
>
> yes, but currently, such a scalar product is not available, is it?
No, but it really should. That's actually the very first feature I
wrote when I implemented root systems in MuPAD. But it was trivial to
achieve with MuPAD coercion's system (one just had to overload the
scalar operator with one implementation for a couple pairs of spaces);
it's currently a bit more tedious in Sage. Hopefuly I'll get to
improve Sage's coercion system this Spring.
> Also conceptually, these coefficients are used to define the
> coweights, so it seems to me like the wrong way to access them. Or
> am I wrong?
That's how all dual bases are defined: this does not prevent them to
be useful computationaly. Of course, one cannot simultaneously
*construct* a dual basis from the scalar product, and use the dual
basis to implement the scalar product. But that's no issue here.
Cheers,
Nicolas
--
Nicolas M. Thiéry "Isil" <nthi...@users.sf.net>
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.
