RFC: a good name the category of algebras that are not necessarily associative nor unital

[Nicolas M. Thiery]

Dear category fans,

One of the features introduced by the category patch #10963 is a new
category for algebras that are not necessarily associative nor unital.
This is a call for suggestions and votes for a good name for it.

- ``Algebras``: that's wikipedia's choice [1]. However using this name
would be backward incompatible, since ``Algebras'' in Sage currently
refers to associative unital algebras. At this point in time, I
don't want to open another can of worm on a ticket that is already
way too big. But we could think about it in a later ticket.

Note: many textbooks/papers use algebra as a short hand for
associative unital (and sometimes commutative) algebras; but they
usually specify this explicitly at the beginning, and they are each
in a smaller context than Sage's.

- ``NonAssociativeNonUnitalAlgebras``: that's what's currently
used in the patch. Of course this terminology is not great because
an associative algebra would then be a special case of a non
associative algebra ...

Note: I remember someone mentioning once that there was a tiny
difference between ``non-associative'' and ``not associative'' that
could possibly make this acceptable but I have no informed opinion
myself.

- ``MagmaticAlgebras``: this was suggested by Florent, referring to
the terminology used in the operad community; see e.g. 13.8 of
Loday&Valette [2]

- Something else?

Thanks for your feedback!

Cheers,
Nicolas

[1] http://en.wikipedia.org/wiki/Algebra_%28ring_theory%29
[2] http://math.unice.fr/~brunov/Operads.pdf

--
Nicolas M. Thi�ry "Isil" <nth...@users.sf.net>
http://Nicolas.Thiery.name/

[Nicolas M. Thiery]

On Wed, Jul 03, 2013 at 03:21:34PM +0200, Nicolas M. Thiery wrote:
> One of the features introduced by the category patch #10963 is a new
> category for algebras that are not necessarily associative nor unital.
> This is a call for suggestions and votes for a good name for it.

On a similar note: this ticket also introduces a category for sets
(E,+,*) where (E,+) is an additive magma, (E,*) is a magma, and *
distributes over +. In other words a ring with no axiom whatsoever but
distributivity. In the current patch, this category is dubbed
DistributiveMagmasAndAdditiveMagmas, by lack of creativity ...

Better suggestions welcome!

In the longer run, I'll also need a name for the same category,
without the distributivity axiom.

Cheers,
Nicolas

[Travis Scrimshaw]

Hey Nicolas,

   For the category of non-unital rings, how about Rngs? (I'm half joking.) Somewhat more serious, GeneralAlgebras/GeneralRings? I think overall we should be consistent between rings and algebras. On the math side of things, doesn't a ring in general has to be distributive; if so, then I think (distributive) non-* rings should be called *Rings and non-distributive things should be MultiplicativeAndAdditiveMagmas (or maybe AdditiveAndMultiplicativeMagmas).

   Also do we want/have a category for skew fields (a.k.a. division rings)?

Best,

Travis

Nicolas M. Thi�ry "Isil" <nth...@users.sf.net>
http://Nicolas.Thiery.name/

[Nicolas M. Thiery]

On Wed, Jul 03, 2013 at 06:47:12AM -0700, Travis Scrimshaw wrote:
> For the category of non-unital rings, how about Rngs? (I'm half joking.)

Actually that joke, for good or bad, is what's already been
implemented in successively Axiom, MuPAD, and Sage :-) They even had
Rigs. And Rgs.

But here we want to go further and remove all other axioms
(associativity, additive inverse, ...) but distributivity.

> Somewhat more serious, GeneralAlgebras/GeneralRings? I think
> overall we should be consistent between rings and algebras.

That would be a plus indeed.

> On the math side of things, doesn't a ring in general has to be
> distributive; if so, then I think (distributive) non-* rings
> should be called *Rings and non-distributive things should be
> MultiplicativeAndAdditiveMagmas (or maybe
> AdditiveAndMultiplicativeMagmas).

Thanks for your input.

> Also do we want/have a category for skew fields (a.k.a. division
> rings)?

sage: Rings().Division()
Category of division rings
sage: Rings().Division().Commutative()
Category of fields
sage: Rings().Division().Finite()
Category of finite fields

:-)

Cheers,
Nicolas
--
Nicolas M. Thi�ry "Isil" <nth...@users.sf.net>
http://Nicolas.Thiery.name/

[Julien Puydt]

Le 03/07/2013 15:38, Nicolas M. Thiery a �crit :

> On Wed, Jul 03, 2013 at 03:21:34PM +0200, Nicolas M. Thiery wrote:
>> One of the features introduced by the category patch #10963 is a new
>> category for algebras that are not necessarily associative nor unital.
>> This is a call for suggestions and votes for a good name for it.
>
> On a similar note: this ticket also introduces a category for sets
> (E,+,*) where (E,+) is an additive magma, (E,*) is a magma, and *
> distributes over +. In other words a ring with no axiom whatsoever but
> distributivity. In the current patch, this category is dubbed
> DistributiveMagmasAndAdditiveMagmas, by lack of creativity ...

DistributiveDoubleMagma?

> Better suggestions welcome!
>
> In the longer run, I'll also need a name for the same category,
> without the distributivity axiom.

DoubleMagma?

Snark on #sagemath

[anne1.s...@gmail.com]

On 7/3/13 6:21 AM, Nicolas M. Thiery wrote:

	Dear category fans,

One of the features introduced by the category patch #10963 is a new
category for algebras that are not necessarily associative nor unital.
This is a call for suggestions and votes for a good name for it.

- ``Algebras``: that's wikipedia's choice [1]. However using this name
  would be backward incompatible, since ``Algebras'' in Sage currently
  refers to associative unital algebras. At this point in time, I
  don't want to open another can of worm on a ticket that is already
  way too big. But we could think about it in a later ticket.

  Note: many textbooks/papers use algebra as a short hand for
  associative unital (and sometimes commutative) algebras; but they
  usually specify this explicitly at the beginning, and they are each
  in a smaller context than Sage's.

- ``NonAssociativeNonUnitalAlgebras``: that's what's currently
  used in the patch. Of course this terminology is not great because
  an associative algebra would then be a special case of a non
  associative algebra ...

  Note: I remember someone mentioning once that there was a tiny
  difference between ``non-associative'' and ``not associative'' that
  could possibly make this acceptable but I have no informed opinion
  myself.

- ``MagmaticAlgebras``: this was suggested by Florent, referring to
  the terminology used in the operad community; see e.g. 13.8 of
  Loday&Valette [2]

- Something else?

MagmaticAlgebras or perhaps AlgebrasOverMagmas or Magma-Algebras (in analogy to an
R-module) seems to be what you want?
See https://en.wikipedia.org/wiki/Magma_%28algebra%29

Otherwise, Travis' suggestion of GeneralAlgebras and GeneralRings would also
be good (if it is explained in the documentation why this name was chosen)!

Best,

Anne

[Simon King]

Hi!

On 2013-07-03, anne1.s...@gmail.com <anne1.s...@gmail.com> wrote:
> MagmaticAlgebras or perhaps AlgebrasOverMagmas or Magma-Algebras (in analogy to an
> R-module) seems to be what you want?
> See https://en.wikipedia.org/wiki/Magma_%28algebra%29
>
> Otherwise, Travis' suggestion of GeneralAlgebras and GeneralRings would also
> be good (if it is explained in the documentation why this name was chosen)!

I don't really like "magma algebra" or "magmatic algebra", but that's mainly because
I never heard anyone using this notion before. I'd rather describe an algebra as a
module over an appropriate operade than call it "magma algebra".

What I'd prefer is very simple: Just say "algebra" to an algebra. If any additional
axiom holds, then the algebra should be called commutative, associative, unital,
noetherian, lie, finite-dimensional, or whatever you like. But don't mention the
*absence* of axioms!

The only problem is that this very simple solution is backward
incompatible, because unfortunately Algebras() returns the category of
*associative* *unital* algebras, in Sage. That's bad. And we would not want
to deprecate the "Algebras()" command: Not the command itself should be
deprecated, but its current semantic should be deprecated. So, how could a
smooth transition be obtained?

Best regards,
Simon

[anne1.s...@gmail.com]

Hi Simon,

I don't really like "magma algebra" or "magmatic algebra", but that's mainly because
I never heard anyone using this notion before. I'd rather describe an algebra as a
module over an appropriate operade than call it "magma algebra".

What I'd prefer is very simple: Just say "algebra" to an algebra. If any additional
axiom holds, then the algebra should be called commutative, associative, unital,
noetherian, lie, finite-dimensional, or whatever you like. But don't mention the
*absence* of axioms!

The only problem is that this very simple solution is backward
incompatible, because unfortunately Algebras() returns the category of
*associative* *unital* algebras, in Sage. That's bad. And we would not want
to deprecate the "Algebras()" command: Not the command itself should be
deprecated, but its current semantic should be deprecated. So, how could a
smooth transition be obtained?

I understand your point and think just Algebras would also be perfect (if it was not
for the backward incompatibilty). How about GeneralAlgebras for now and then
a deprecation/switch in a later patch?

Best,

Anne 

[Thierry]

Hi,

On Wed, Jul 03, 2013 at 08:43:06PM +0000, Simon King wrote:
> What I'd prefer is very simple: Just say "algebra" to an algebra. If
> any additional axiom holds, then the algebra should be called
> commutative, associative, unital, noetherian, lie, finite-dimensional,
> or whatever you like. But don't mention the *absence* of axioms!

+1 for this proposal. I think this is not the role of Sage to change
existing mathematical notations/definitions.

In Lang, Algebra (3rd ed., page 121), it is stated that the restriction
to associative and unital algebras is made for the book only.

It is a pity that the name is already used for a more restrictive
notion, but i think that this backward incompatible change is better
that the other currently proposed solutions. Perhaps could we list and
fix all similar misnamings or annoyances during a change of major
version (e.g. Sage 6.0) and announce this clearly, so that we will
suffer only once ?

Ciao,
Thierry

> The only problem is that this very simple solution is backward
> incompatible, because unfortunately Algebras() returns the category of
> *associative* *unital* algebras, in Sage. That's bad. And we would not want
> to deprecate the "Algebras()" command: Not the command itself should be
> deprecated, but its current semantic should be deprecated. So, how could a
> smooth transition be obtained?
>
> Best regards,
> Simon
>
>

> --
> 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+...@googlegroups.com.
> To post to this group, send email to sage-...@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Volker Braun]

+1 for switching Algebras to CommutativeUnitalAlgebras (or so) and the using Algebras for the most general algebra.

In fact, I don't understand why Algebras has to be in the global namespace. I've never once found it useful to start an interactive session by instantiating a new category. The docstring isn't particularly useful either. Essentially, it is only is a trap for newcomers. Unless somebody has a really good use case I wouldn't mind removing all categories from the global namespace and implicitly making their name an implementation detail subject to change as the category hierarchy matures.

[Dima Pasechnik]

On 2013-07-04, Volker Braun <vbrau...@gmail.com> wrote:
> ------=_Part_6640_25172370.1372980267137
> Content-Type: text/plain; charset=ISO-8859-1

>
> +1 for switching Algebras to CommutativeUnitalAlgebras (or so) and the
> using Algebras for the most general algebra.

++

all these "magma" or "generic" are quite confusing.

>
> In fact, I don't understand why Algebras has to be in the global namespace.
> I've never once found it useful to start an interactive session by
> instantiating a new category.

+1
(although full-time category theorists might disagree :))

[Simon King]

Hi Dima,

On 2013-07-05, Dima Pasechnik <dim...@gmail.com> wrote:
>> In fact, I don't understand why Algebras has to be in the global namespace.
>> I've never once found it useful to start an interactive session by
>> instantiating a new category.
> +1
> (although full-time category theorists might disagree :))

I think I am only part-time categorist.

On the one hand, I too think that there is currently no need to insert
categories into the global namespace. Categories do a lot of useful stuff
in the background, but usually they do not show up in the foreground.

On the other hand, this might actually change with Nicolas' upcoming
functorial constructions patch. If Sage would be able to really do fancy
constructions with categories, then it would certainly make sense to do/test
these constructions in an interactive session.

On the third hand (on the one foot??), if one wants to do arithmetics *on*
categories (rather than just arithmetics *using* categories), then one can
still do something like "from sage.categories import *" without too much
effort.

On the other foot, removing categories from the global namespace would
probably break a lot of tests. How should this be organised? On the functorial
constructions ticket, which already is big enough? On a later ticket? On
an earlier ticket?

Best regards,
Simon

[Franco Saliola]

On Jul 5, 2013 7:13 AM, "Simon King" <simon...@uni-jena.de> wrote:
>
> Hi Dima,
>
> On 2013-07-05, Dima Pasechnik <dim...@gmail.com> wrote:
> >> In fact, I don't understand why Algebras has to be in the global namespace.
> >> I've never once found it useful to start an interactive session by
> >> instantiating a new category.
> > +1
> > (although full-time category theorists might disagree :))
>
> I think I am only part-time categorist.
>
> On the one hand, I too think that there is currently no need to insert
> categories into the global namespace. Categories do a lot of useful stuff
> in the background, but usually they do not show up in the foreground.
>
> On the other hand, this might actually change with Nicolas' upcoming
> functorial constructions patch. If Sage would be able to really do fancy
> constructions with categories, then it would certainly make sense to do/test
> these constructions in an interactive session.
>
> On the third hand (on the one foot??), if one wants to do arithmetics *on*
> categories (rather than just arithmetics *using* categories), then one can
> still do something like "from sage.categories import *" without too much
> effort.

I like the idea of being able to do

    categories.<tab>

and seeing a list of the available categories (or some reasonable subset of).

For the record, I like the term magmatic algebras. It is not standard/common terminology and would certainly invite the user to look at the documentation to figure out what it is.

Franco

>
> On the other foot, removing categories from the global namespace would
> probably break a lot of tests. How should this be organised? On the functorial
> constructions ticket, which already is big enough? On a later ticket? On
> an earlier ticket?
>
> Best regards,
> Simon
>
>
>

[Simon King]

Hi Franco,

On 2013-07-05, Franco Saliola <sal...@gmail.com> wrote:
> I like the idea of being able to do
>
> categories.<tab>
>
> and seeing a list of the available categories (or some reasonable subset
> of).

... which would not require them being inserted into the global
namespace, AFAIK.

> For the record, I like the term magmatic algebras. It is not
> standard/common terminology and would certainly invite the user to look at
> the documentation to figure out what it is.

When do you ever see the category of a parent P? In addition, there currently
is no non-associative algebra in Sage, hence, even if you do
P.category(), you would not see "Category of magmatic algebras".

Best regards,
Simon

[Volker Braun]

On Friday, July 5, 2013 7:33:49 AM UTC-4, Franco Saliola wrote:

   categories.<tab>

That would be nice, too. Then you don't get useless (for interactive use) categories showing up when you use tab-completion to search for non-category stuff but you can still write doctests without having to import stuff manually.

[Franco Saliola]

Let me make my vote more precise: I like magmatic algebra as a temporary solution; otherwise I concur with Simon that we should redefine the current category Algebras.

Franco

--

[Dima Pasechnik]

On 2013-07-05, Franco Saliola <sal...@gmail.com> wrote:

> --089e0112cf9a05cdd104e0c5e9eb
> Content-Type: text/plain; charset=ISO-8859-1

IMHO there should also be some consistency here, e.g. then one should
have magmatic rings...

Dima
>
> Franco

[Peter Bruin]

Dear all,

While working on an implementation of finite algebras over fields (#12141) I was slightly annoyed by the fact that Algebras are currently assumed to be unital.  I agree with Simon King's opinion:

I don't really like "magma algebra" or "magmatic algebra", but that's mainly because
I never heard anyone using this notion before. I'd rather describe an algebra as a
module over an appropriate operade than call it "magma algebra".

What I'd prefer is very simple: Just say "algebra" to an algebra. If any additional
axiom holds, then the algebra should be called commutative, associative, unital,
noetherian, lie, finite-dimensional, or whatever you like. But don't mention the
*absence* of axioms!

Best regards,

Peter Bruin

[Nicolas M. Thiery]

Dear category fans,

Thanks everybody for your feedback in this discussion! Let me try to
make a synthesis.

(1) In the long run, Algebras(R) should match with Wikipedia's
definition and not assume any axiom: an algebra A is an R-module
with a binary multiplication which is bilinear.

Note that this might not be the end of the discussion: at some
point we will want to support R to be just a semiring and in this
case `A` we would not necessarily need to require A to have
additive inverses. But one problem at a time.

(2) Point (1) is a backward incompatible change, which will take some
work. There is already enough on our plate with #10963, so this
change is postponed for later. For now we need a temporary name.
The two current suggestions are:

- NonAssociativeNonUnitalAlgebras
- MagmaticAlgebras

The former is actually technically correct in English (though not
so nice). In any cases, there seems to be a preference of the
latter (this means more work for me, but so be it).

Note: MagmaAlgebras is not an option as it is confusing. Since we
call "group algebra" the algebra of a group, a "magma algebra"
stands naturally for the algebra of a magma.

(3) For the related situation of a multiplicative magma that
distributes over a magma, there are two suggestions currently:

- DistributiveMagmasAndAdditiveMagmas
- MagmaticRing

The first one is ugly but rather explicit. The second one is
consistent with MagmaticAlgebras, though we don't care so much
since MagmaticAlgebras will eventually disappear. By default I'll
stick with the former to save time, but I could bend under popular
pressure.

(4) There are way too many categories in the global name space.
There is for example no reason to have
FiniteDimensionalHopfAlgebrasWithBasis(QQ) there.

Some people further said that there is actually no reason
whatsoever to have any category in the global name space because
"categories are only for the programmer". I object to that
part. The following are perfectly natural things a user would want
to do with categories:

sage: A in Fields() # Is A known to be a field?
sage: Hom(F, G, Groups()) # Construct a homset in a given category
sage: Groups? # What is a group?
sage: Groups().example() # Give me an example
sage: S = Semigroups().example(); S?? # Show me the code!
sage: DivisionRings() & Sets().Finite() # Please remind me about Wedderburn
Category of finite fields
sage: Fields().all_implementations() # All fields in Sage (Florent has some code toward this)
sage: MatrixGroup(..., category = FiniteGroups()) # I promise that the result is actually finite

In short, categories are about the mathematics in Sage and we want
our user to use and explore this mathematics.

Of course #10963 will allow to considerably reduce the number of
entry points being actually imported by default since e.g.:

FiniteGroups() can now be Groups().Finite(),
GradedHopfAlgebrasWithBasis() can now be HopfAlgebras().Graded().WithBasis()

I could possibly be convinced to further reduce the pollution by
making the categories accessible as categories.Groups() instead of
Groups().

In any cases, this will be for after #10963.

(5) The docstring of many categories could take some love as it is an
important entry point for users. Volunteers are welcome once
#10963 will have been merged.