Hi Simon, On Fri, Oct 08, 2010 at 04:00:06AM -0700, Simon King wrote: > Currently I try to re-implement free algebras. Aim: Make arithmetic at > least 10 times faster, use the coercion model, and also provide non- > associative and non-unital algebras.
Great! See also: http://groups.google.com/group/sage-devel/browse_thread/thread/107f0ce9b58fca59/a60294d361af24c7 > I am also using the category framework for the first time -- quite > useful! I am glad it works for you :-) > But the work in categories led to some questions. > > On the one hand, there is > sage: MonoidAlgebras(QQ) > Category of monoid algebras over Rational Field > > On the other hand, there is > sage: Monoids().Algebras(QQ) > Category of monoid algebras over Rational Field > > But > sage: MonoidAlgebras(QQ) == Monoids().Algebras(QQ) > False > > The two categories are indeed different: Monoids().Algebras(...) > provides the parent method "one_basis", but MonoidAlgebras(...) > doesn't. > > - Shouldn't the two categories of monoid algebras be merged? Yes! My intent is to deprecate MonoidAlgebras in favor of Monoids().Algebras(...), the latter being more flexible. There is just one thing I am not sure with: if M is a parent in Monoids().Algebras(...) then the category does make the assumption that the elements of M are represented by their expansion in the canonical basis of elements of the group. Yet, there might be a need for a category whose parents would model algebras which are *isomorphic* to a monoid algebra through some change of basis (e.g. Fourier transform); if not just because this can bring mathematical information: for example, in the case of a group and in the non modular case the algebra is semi-simple. Possibly MonoidAlgebras could be kept for this usage, though this could be quite confusing. > My questions: > - It seems to me that the semantics of "one_basis" does not really > belong to a mathematical category. So, shouldn't this method (and > similar methods) better be removed from the category and put into a > base class? one_basis does convey (and implement!) a piece of mathematical information which is valid for any monoid algebra: namely that the unit of the algebra is given by the basis element indexed by the unit of the monoid. That's why I put it in the category. > I envision the following: > > - The category "Algebras(...)" should merely be a synonym for > "Magmas().Algebras(...)". No: Magmas().Algebras(...) is for non associative algebras where the product of two basis elements is again a basis element, according to the product law of the underlying magma. This includes many interesting algebras (free algebras, polynomial rings, ...), but most algebras are not of this form (invariant rings, Weyl algebras, ...). > Similarly, MonoidAlgebras(...) should be a synonym for > "Monoids().Algebras(...)". Probably yes. Or just deprecated. > - The category "Magmas()" should provide two additional parent > methods is_associative and is_unital. The default implementation of > the former would test that "self" is in Semigroups() And if not, and in the finite case, run a systematic test. > the default of the latter would test whether self.one() raises an > error. Well, first test if ``self`` is in Monoids(), and then ... By the way: in general I am not super keen on those is_* methods. In my view, they are useful for the user who wants to explore the properties of some newly created parent. But code should do tests based on ``self in *s()``. > - Similar methods should be provided by "Algebras(...)", being > derived from the corresponding methods of the underlying base ring > and the underlying magma. Yup (but by Magmas().Algebras(...) due to the above discussion). > - The categories should be stronger interrelated. For example, isn't > any ring also an associative algebra (aka semigroup algebra) over > itself? Isn't any algebra over a ring R also an algebra over any ring > that coerces into R? These facts should be reflected in Sage's > category framework, IMO. Yes, this would be great. MuPAD did part of that (at least a ring was an algebra over itself), but at the price of a hack (the category inheritance depended on the parent at hand). At this point I don't know how to implement it. See http://trac.sagemath.org/sage_trac/wiki/CategoriesRoadMap. Just to clarify: a ring is indeed a semigroup algebra over itself (taking the trivial semigroup). And semigroup algebras indeed are associative. But as above, not any associative algebra is a semigroup algebra. Looking forward progress in those directions! Cheers, Nicolas -- Nicolas M. Thiéry "Isil" <[email protected]> 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
