Hi Nicolas and the rest, On Thursday, November 29, 2012 5:14:16 PM UTC+1, Nicolas M. Thiery wrote: > > My question was: is this a feature you need, or do you just want not > to be bitten by it in case it is used accidently. >
Sorry, I missunderstood the question. Exactly, what I was doing is the following: I have all the roots of E8, apply a projection condition and, with some code, identify from the surviving roots the irreducible Cartan types, returning a list of them. Some times (e.g. trivial projection condition), the list has just one member (in the example, [["E",8]]). In order to test my identification of the Cartan types, I would find the simple roots in the surviving root system, compute the Cartan matrix and compare it with the one from CartanType[<result>], where <result> is the list of types identified. But things like CartanType([["E",8]]).cartan_matrix() just fail, as we know. What I did is of course fix it on my side, using the same two lines as in the patch. Anyway, as it is a mathematically wrong answer, I decided to report a bug. So, let me dare to say that we disagree with the first two possibilities and look at the last two: > - Return the underlying CartanType A (that's what the current patch > implements). That's mathematically correct. However, having a non > uniform behavior in corner cases typically forces any caller code to > handle explicitly the special cases. For example, in the case at > hand, the nodes of the Dynkin diagram would not get relabeled; also > the ambient space would not have an inject_weights method, etc. Maybe it is a naïve question, but why would we want the relabelling or the weight injection if we actually have an irreducible type? > Btw: if we go in this direction, we should add tests, in particular > for the corner-corner case: CartanType([[A]]). > I disagree there: this is not a corner-corner case, but plain wrong input, which do not fit in any of the examples given in the docstring. Still, it could be easily incorporated by changing the "if" in the patch for a "while". > - Rename type_reducible to type_direct_product, and fix is_irreducible > and friends to handle the special case properly. But it's a bit more > work. I guess it would be enough to remove the definition of > is_irreducible, and use a trick in the initialization like for > type_relabel, to make the result inherit from CartanType_simple when > relevant. > That seems to me innecesarily complicated, maybe because I am missing your point, maybe because I don't see "my" corner case as an special case, but as a normal case which is handled wrongly. Could you, please, elaborate on this point a little more? > At this point, I guess my preference goes for the last > option. Especially if you would volunteer for doing it :-) > Whichever option is chosen, I volunteer, as long as there are no hard time constraints: I certainly enjoy this, but the last year of a PhD is maybe not the best moment to start working too much in anything else than one's thesis :( Cheers, Jesús Torrado -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To view this discussion on the web visit https://groups.google.com/d/msg/sage-combinat-devel/-/EpQwBMS267IJ. 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.
