On Wed, Nov 28, 2012 at 01:42:30PM -0800, JesusTorrado wrote:
> Well, I found it while working and took me a while to figure out the
> cause, so I am biased towards considering it worse than a corner case :)
Calling something a corner case is not derogatory :-) Having robust
corner cases is definitely critical for code safety!
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.
Anyway, let me add a bit of context for newcomers to the discussion).
CartanType([A,B,C]) constructs a CartanType as a direct product of
the Cartan types A, B, and C. I.e. the Dynkin diagram is the disjoint
union of those for A, B, C, with the nodes relabeled to avoid
conflicts. This direct product is thus irreducible. Well, almost. The
question is how to handle properly the corner case of a direct product
of a single cartan type, as in CartanType([A]).
My dilemma is as follow. We could:
- Leave things as they are. But that's mathematically wrong since, as
you report, CartanType([A]).is_irreducible() returns False.
- Forbid the construction of a direct product of a single CartanType.
That would be safe; however experience tells that forbidding corner
cases is annoying (e.g. the empty partition/permutation/matrix/...).
- 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.
Btw: if we go in this direction, we should add tests, in particular
for the corner-corner case: CartanType([[A]]).
- 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.
At this point, I guess my preference goes for the last
option. Especially if you would volunteer for doing it :-)
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.
