[sage-combinat-devel] Re: bug in WeylGroup?
Nicolas, I think the classical lattice of an affine coroot lattice should be a finite coroot lattice. Coroot lattices should be paired with weight lattices. Yet the code *prevents* me from doing this. This is surely a bug. I don't have a problem with code-sharing and using the co isomorphism between the coroot lattice of type X and the root lattice of type X-dual. But if this isomorphism is used in the implementation, the resulting object should have enough wrapping to remember what kind of object it is and behave accordingly. --Mark sage: Qv=CartanType(['C',2,1]).root_system().coroot_lattice() sage: Q0v = Qv.classical(); Q0v Root lattice of the Root system of type ['B', 2] sage: P=CartanType(['C',2,1]).root_system().weight_lattice() sage: P0=P.classical() sage: P0.an_element().scalar(Q0v.an_element()) Traceback (click to the left of this block for traceback) ... AssertionError -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/groups/opt_out.
[sage-combinat-devel] Re: bug in WeylGroup?
Nicolas, Aha! I found how a lattice can tell it comes from a co construction. This can be used to fix all the ills I have been complaining about. The cost of implementing the coweight lattice of type X as the weight lattice of type X-dual, is that this little dual must be remembered and taken into consideration by any construction that uses a RootLatticeRealization. The dual is remembered in the RootLatticeRealization via the attribute root_system.dual_side: sage: L = CartanType(['B',2]).root_system().coweight_lattice(); L Coweight lattice of the Root system of type ['B', 2] sage: L.cartan_type() ['C',2] Now this seems to me to be a bug. I can work around it if necessary. sage: L.root_system Dual of root system of type ['B', 2] How did it know it was the dual? sage: L.root_system.cartan_type() ['C',2] sage: L.root_system.dual_side True The WeylGroup construction from a RootLatticeRealization, which currently produces a confusing name-string, and the classical method of a RootLatticeRealization, which produces a lattice of the wrong type if it starts with an affine coroot or coweight lattice, should be modified to take this dual into account in the case that the lattice was constructed using a co. Shall I fix this? --Mark Is the following a bug? It seems so. sage: WeylGroup(CartanType(['B',2]).root_system().coweight_lattice()) Weyl Group of type ['C', 2] (as a matrix group acting on the coweight lattice) --Mark -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/groups/opt_out.
[sage-combinat-devel] Re: Should ClasscallMetaclass do a consistency test?
On Tuesday, 30 July 2013 14:18:28 UTC+2, Simon King wrote: Hi all, On 2013-07-29, Simon King simon...@uni-jena.de javascript: wrote: After all, we have a class, and we call the class as if to create an instance---but what we get is in fact not an instance of this class, but is instance of a *totally* different class. OK, it is possible, Python let's you do it. But not all what can be done should be done. I have nothing against the following pattern: ... And I think this pattern is totally fine, since C(...) returns instances of sub-classes of C (namely of A resp. B)---hence, it returns instance of C! I could imagine that a similar pattern would be available for Partition versus PartitionTuple. I determined all classes-with-ClasscallMetaclass that sometimes return instances that are not instances of this class: sage.combinat.composition.Compositions sage.combinat.integer_vectors_mod_permgroup.IntegerVectorsModPermutationGroup sage.combinat.partition.Partitions sage.combinat.partition_tuple.PartitionTuple sage.combinat.posets.poset_examples.Posets sage.combinat.root_system.type_relabel.CartanType sage.combinat.tableau_tuple.StandardTableauTuple sage.combinat.tableau_tuple.StandardTableauTuples sage.combinat.tableau_tuple.TableauTuple sage.combinat.tableau_tuple.TableauTuples plus three classes that seem only to be made for doctests. What do you think? These are relatively few classes. Would it be reasonable to change them, such that when on tries to create instances of these classes then one is guaranteed to actually get an instance of these classes (or a sub-class, at least)? I have no objection provided that the new code continues to respect the underlying *mathematical relationships* between these classes. I think that changing the classes so that they respect semantic niceities whilst breaking the underlying mathematical relationships, which these classes are meant to emulate, would be a mistake. It would also delay my porting into sage what I think is probably the best avilable code for working with representation theory of the symmetric groups in positive characteristic. Andrew -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/groups/opt_out.
