>> We have the category AbelianMonoidRing and also there is >> MonoidRingCategory. Shouldn't at least one be a subcategory of the other? >> >> http://fricas.github.io/api/AbelianMonoidRing >> http://fricas.github.io/api/MonoidRingCategory
> Well, this is another instance of 'monoid problem': AbelianMonoidRing > uses AbelianMonoid as exponents, that is uses '+' for exponent > arithmetic. MonoidRingCategory uses Monoid, that is '*'... Ohhhhh... How could I ovelook this? For my purpose, I have written a wrapper domain AddToMul that turns a AbelianMonoid into a Monoid, i.e., turning + into *, but now I can simply use AbelianMonoidRing. Cool. However, it's still some kind of trap for the programmer. OK, we have to live with it for now. >> Additionally, the docstring for AbelianMonoidRing says: >> >> """ >> The monomials commute with each other, but in general do not commute >> with the coefficients (which themselves may or may not be commutative). >> """ >> >> That sounds as if it were allowed that one could use a non-commutative >> coefficient domain. But according to the types the coefficient domain is >> an AbelianMonoid. > > Which means that '+' for coefficients is commutative. But we do not > require commutative '*'. All the things are clear except the part === the coefficients (which themselves may or may not be commutative) === To me the "which" refers to "coefficients". But the coefficient domain *IS* commutative by specification of R: Join(SemiRng, AbelianMonoid). Ralf -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
