We also should determine how we want to distinguish between (and input)
A_{+oo} and A_{oo}, i.e., index sets of NN and ZZ. In fact, the only place
where I really see this fundamentally breaking is the CartanMatrix and
Dynkin Diagram. All of the root/weight lattice stuff should work since
those are based around Family and CombinatorialFreeModule (although roots()
and friends probably won't work so well).
I don't really see a problem with just implementing a subclass of
CartanType_abstract for A_{+oo}/A_{oo} and allowing the methods to just
raise NotImplementedError's.
Best,
Travis
--
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 https://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.
