before things became to complicated and long names to obey utmost generality, I suggest to think about, whether there are non abelian applications which use the +-symbol. I am curious to here about them.
As long as there is not a real bunch of them and as long there is no concrete plan to extend AXIOM/FriCAS to have group categories with a free chosen operational symbol, I would recommend to keep the usual mathematical convention to have + an abelian operation and to having * to be non commutative or commutative. Johannes Am 18.08.15 um 19:49 schrieb Ralf Hemmecke: >> OK, in analogy with exising names we get AdditiveMagmaWithUnit > That's also OK for me. > >>> I'm not really sure, but maybe we could think of introducing a category >>> that represents the axioms. AdditiveSemigroup is OK for associativity, >>> but, according to https://en.wikipedia.org/wiki/Magma_%28algebra%29 >>> there is also "unital magma", i.e. without associativity. >> AFAICS it is exactly AdditiveMagmaWithUnit (2 above). > I don't care so much whether it is UnitalAdditiveMagma or > AdditiveMagmaWithUnit. In fact, I cannot say which one I like better. > At least "unital magma" should appear somewhere in the documentation, if > it becomes the "...WithUnit" thing. > >>> Although "Abelian" seems to be used consistently, i.e. always only wrt. >>> the + operation, why not continue using "Additive" and "Multiplicative" >>> in the name to avoid confusion? I.e. we would have AbelianAdditiveGroup, >>> AbelianMultiplicativeGroup, etc. >>> >>> Currently, we have Group reserved for *. The respective categories for + >>> always include commutativity. Not perfect, I would say. So I would want >>> AdditiveGroup and MultiplicativeGroup. >> Names can get quite long, like CancellationAbelianMonoid. I think >> when we have opportunity to shorten names without confusion we >> should use it. > Well, yes, that's a good reason. But for me and probably also for others > it's strange that AbelianMonoid does not inherit from Monoid. > If it where AbelianAdditiveMonoid and AbelianMultiplicativeMonoid the > inheritance (from AdditiveMonoid or MultiplicativeMonoid) would be > clear. That's what I meant in my last mail by duplicating some category > hierarchy. > > If names are to long for you then what about Monoid_* and Monoid_+? > Although I don't like too many underscores in names, we could then also > have Semigroup_\_/ and Semigroup_/_\ (instead of JoinSemigroup and > MeetSemigroup). > > For the general category hierarchy, I'm rather in favour of long names > that easily (intuitively?) allow to guess inheritance. I therefore opt > to include "Additive" and "Multiplicative" for the two hierarchies wrt + > and * and reserve the generic names (SemiGroup, Monoid, Group) for the > time when we can rename operations or parametrize op-names in the category. > > Ralf > > -- Mit freundlichen Grüßen Johannes Grabmeier Prof. Dr. Johannes Grabmeier Köckstraße 1, D-94469 Deggendorf Tel. +49-(0)-991-2979584, Tel. +49-(0)-151-681-70756 Tel. +49-(0)-991-3615-141 (d), Fax: +49-(0)-3224-192688 -- 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 http://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
