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.
Cheers,
Nicolas
--
Nicolas M. Thiéry "Isil" <nthi...@users.sf.net>
http://Nicolas.Thiery.name/
--
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+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.
