Hi, I don't know which of the following is better in the "three M"'s as I have close to no experience with them, but I suspect at least the documentation part is...
- Dima Pasechnik mentioned representation theory of associative algebras, but even linear algebra over fields is not implemented in Sage when the vector spaces are not given as R^n or R^m but as CombinatorialFreeModules. This can be worked around in any specific situation by mapping them to R^n and R^m, but the work required grows with the complexity of the question, and this ends up being severely limiting. - Implementers of classes have to make decisions which really should be left to users of their classes. When you create your class of (say) posets, you have to decide whether to cache covering relations or to compute them every time as needed; whether to compute certain invariants when the class is being created or only later; how to represent the data internally; etc.. But there is no right way to make such decisions; it all depends on the user and whether he is planning to study one or two posets in detail or to generate thousands of them as intermediate steps of an algorithm. (For a better example, we recently had a discussion of how much information about a Coxeter group should be computed at the moment of its creation.) We should IMHO use abstract classes more often, but I see very few examples of this in Sage. - Documentation. Sorry, but much of it reads like mason's marks from thousand years ago; particularly on underscored methods (I think people believe that underscore means noone will ever want to use it, but that's not true). Best regards, Darij -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
