so let me add one first counterexample myself: String concatenation sometimes is written with + - and therefore it is clear that there is no + for String in AXIOM
Am 18.08.15 um 21:11 schrieb Prof. Dr. Johannes Grabmeier privat: > 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 Fraktionsvorsitzender FREIE WÄHLER, Stadtrat Deggendorf Prof. Dr. Johannes Grabmeier Köckstraße 1, D-94469 Deggendorf Tel. +49-(0)-991-2979584, Tel. +49-(0)-151-681-70756 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.
