[sage-combinat-devel] RFC: a good name the category of algebras that are not necessarily associative nor unital
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 LodayValette [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 nthi...@users.sf.net http://Nicolas.Thiery.name/ -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/groups/opt_out.
[sage-combinat-devel] Re: RFC: a good name the category of algebras that are not necessarily associative nor unital
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 -- 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-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/groups/opt_out.
[sage-combinat-devel] Re: RFC: a good name the category of algebras that are not necessarily associative nor unital
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 On Wednesday, July 3, 2013 3:38:00 PM UTC+2, Nicolas M. Thiery wrote: 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 -- Nicolas M. Thi�ry Isil nth...@users.sf.net javascript: http://Nicolas.Thiery.name/ -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-combinat-devel] Re: Skew tableaux
Hi, Oops, per popular request, let me be a bit more specific: what is CAT complexity Constant Amortized Time; roughly speaking this means that, in average, each step of the iteration takes a constant amount of time: http://stackoverflow.com/questions/200384/constant-amortized-time In practice, since we usually create a full new element at each step of the iteration, we can't really achieve CAT; so it's fair to aim at an amortized time complexity that is linear in the size of the elements that are iterated through. and how can one use crystal operations for generation of all SSYT? Do they form a connected digraph on the set of all SSYT with given max_entry and shape?) Precisely. You get all SSYT from the highest weight one by applying successively the f (or e? I never know) crystal operators: sage: CrystalOfTableaux(['A',2], shape = [3,2]).list() [[[1, 1, 1], [2, 2]], [[1, 1, 2], [2, 2]], [[1, 1, 3], [2, 2]], [[1, 1, 3], [2, 3]], [[1, 2, 3], [2, 3]], [[1, 1, 3], [3, 3]], [[1, 2, 3], [3, 3]], [[2, 2, 3], [3, 3]], [[1, 1, 1], [2, 3]], [[1, 1, 2], [2, 3]], [[1, 2, 2], [2, 3]], [[1, 1, 1], [3, 3]], [[1, 1, 2], [3, 3]], [[1, 2, 2], [3, 3]], [[2, 2, 2], [3, 3]]] And there is a way to build an iterator out of those operations that is essentially CAT; see ClassicalCrystals.ParentMethods.__iter__. 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-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/groups/opt_out.
[sage-combinat-devel] Re: RFC: a good name the category of algebras that are not necessarily associative nor unital
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 nthi...@users.sf.net http://Nicolas.Thiery.name/ -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-combinat-devel] RFC: a good name the category of algebras that are not necessarily associative nor unital
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 LodayValette [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 -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/groups/opt_out.
[sage-combinat-devel] Re: Skew tableaux
I would like to chime in on what Anne said. I would rather see that Tableau and Tableaux be able to handle skew-tableaux than copy-paste the tableaux functions into skew-tableaux. There is functionality in SkewTableau which is not in Tableau (cells_by_content, entries_by_content) and vice versa. -Mike On Monday, 1 July 2013 15:06:46 UTC-4, darijgrinberg wrote: Hi all (Travis in particular since he's working on the file), A few days ago, the lack of functionality in combinat/skew_tableau.py (as opposed to combinat/tableau.py) bit me: I was trying to generate all skew semistandard tableaux of a given shape with a given max_entry, and noticed that there is no such option. This isn't the only thing missing, and it seems that skew_tableau.py never got the love that tableau.py received during development. Are there any updates to the file floating around between combinat people? I am aware of trac #14101 (which depends on #14772, which conflicts with #14808; but even without #14808, the #14101 patch fails on my sage-5.11beta3 at patching sage/combinat/integer_vector_weighted.py for some reason). But as far as I understand, this mainly changes the OOP structure, while leaving the functionality as it is; right, Travis? Anyway, I'm assuming this is the wrong time for me to mess with the file, but once Travis's stuff is positively reviewed, would it be a good idea to basically copypaste the structure of tableau.py into skew_tableau.py (with the appropriate changes to the algorithms), or do you think tableau.py is a mess and should not be imitated? (I'm asking because such things were told to me about some parts of the code; I don't have particular reservations about tableau.py.) Best regards, Darij -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/groups/opt_out.
