[sage-devel] Re: Category help

[John H Palmieri]

On Saturday, June 16, 2018 at 7:39:46 PM UTC-7, Travis Scrimshaw wrote:
>
>
> An implementation question: separately from having a category of super 
>> commutative algebras, I could imagine wanting the option to use a tensor 
>> product of graded algebras which includes a sign in the product:
>>
>> (x1 tensor y1) (x2 tensor y2) = (-1)^(deg y1 deg x2) (x1 x2 tensor y1 
>> y2)
>>
>> even if neither tensor factor is itself (graded) commutative. How would 
>> this be implemented? Define a new tensor product? And then somehow label 
>> the category in which the algebra lives to tell it to use that tensor 
>> product? Or define an axiom? (Are axioms worth using? I have run into 
>> problems with inheritance with axioms.)
>>
>> This is a bit of a tricky issue. Of course, you could define a new 
> TensorProducts category that implements a product_on_basis with this 
> version (see AlgebrasWithBasis.TensorProducts.ParentMethods). If the tensor 
> product parent was in that category (likely just being a 
> CombinatorialFreeModule), then it should work out of the box. I am not sure 
> this fits the criteria to be an axiom (but they are definitely worth using 
> in the appropriate circumstances). The can of worms comes out when you want 
> a natural way to construct that parent in that category. Plus a good name 
> will be needed, but I guess the natural place would be part of the 
> SuperAlgebras.Commutative.TensorProducts category.
>
> Best,
> Travis
>
>
After thinking about this more, I believe that tensor products are a more 
important feature to implement. It would be nice to have a category of 
supercommutative super algebras (or whatever we want to call them), but in 
practice, most implementations will build the supercommutativity into the 
product structure, by defining product_on_basis appropriately. So having a 
category of supercommutative super algebras would be convenient, but it 
wouldn't add much functionality.

So I would put a higher priority on a SignedTwistTensorProduct construction 
(or whatever we want to call it: the map (A tensor B) -> (B tensor A) is 
often called the twist map, and we want to impose a sign on it). This 
should be available even if A and B are not themselves (super) commutative. 
If they are supercommutative, then this would be part of the structure that 
they should inherit. I've opened #25603 
 for this but given my 
understanding of Sage's category code, I'm not sure I'm up to the task.

-- 
John

(1) https://trac.sagemath.org/ticket/25603

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Category help

[Simon King]

Hi Travis,

On 2018-06-17, Travis Scrimshaw  wrote:
> Then IMO it should be SuperCommutative/super-commutative. Yet, I do not 
> think there will be any ambiguity over the meaning of a commutative 
> superalgebra, which is why I was suggesting to use the Commutative axiom. 

Yes, but by using that axiom you would (I think) automagically get
superalgebras that are commutative in the ordinary (not super!) sense.

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

[sage-devel] Re: Category help

[Travis Scrimshaw]

Then IMO it should be SuperCommutative/super-commutative. Yet, I do not 
think there will be any ambiguity over the meaning of a commutative 
superalgebra, which is why I was suggesting to use the Commutative axiom. 
Also, it means you get things like a super-commutative superalgebra.

Best,
Travis


On Sunday, June 17, 2018 at 5:32:57 PM UTC+10, Simon King wrote:
>
> Hi Travis and John, 
>
> On 2018-06-17, Travis Scrimshaw > wrote: 
> > IMO, proper way to implement this is as a CategoryWithAxiom as a part of 
> > SuperAlgebras[WithBasis]. So you add a class 
> > "Commutative(CategoryWithAxiom_over_base_ring)" to the 
> > SuperAlgebras[WithBasis] category and do the normal category 
> implementation 
> > stuff there. 
>
> I disagree. 
>
> In a previous post (IIRC), John has emphasised that he is dealing with 
> graded 
> commutative algebras, which are of course not commutative algebras 
> (indeed, 
> x*y=-y*x when x,y are of odd degree). 
>
> So, it would actually be mathematically wrong to use the axiom 
> "Commutative" 
> here (in one way or another) because graded commutative algebras are not 
> commutative, and are thus not sub-categories of CommutativeMonoids (which 
> would be the effect of using the "Commutative" axiom. 
>
> I think the proper way to proceed is: Add a new axiom "GradedCommutative", 
> that is defined for GradedRings(). Then, 
> GradedAlgebrasWithBasis(QQ).GradedCommutative() would automatically be 
> available (as GradedAlgebrasWithBasis(QQ) is a sub-category of 
> GradedAlgebras(QQ), returning the "Category of graded commutative 
> graded algebras with basisover Rational Field", and I think that's what 
> John wanted (if I recall his previous post correctly). 
>
> 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+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: Category help

[John Cremona]

https://en.m.wikipedia.org/wiki/Graded-commutative_ring

has the hyphen so +1

On Sun, 17 Jun 2018, 08:37 Simon King,  wrote:

> PS:
>
> On 2018-06-17, Simon King  wrote:
> > I think the proper way to proceed is: Add a new axiom
> "GradedCommutative",
> > that is defined for GradedRings().
>
> It might actually be a good idea to overrided the default string
> representation of that new axiom. The default is "graded commutative",
> which people might misunderstand as "graded and commutative". So, having
> a hypen as in "graded-commutative" would be more accurate.
>
> --
> 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 https://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Category help

[Simon King]

PS:

On 2018-06-17, Simon King  wrote:
> I think the proper way to proceed is: Add a new axiom "GradedCommutative",
> that is defined for GradedRings().

It might actually be a good idea to overrided the default string
representation of that new axiom. The default is "graded commutative",
which people might misunderstand as "graded and commutative". So, having
a hypen as in "graded-commutative" would be more accurate.

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Category help

[Simon King]

Hi Travis and John,

On 2018-06-17, Travis Scrimshaw  wrote:
> IMO, proper way to implement this is as a CategoryWithAxiom as a part of 
> SuperAlgebras[WithBasis]. So you add a class 
> "Commutative(CategoryWithAxiom_over_base_ring)" to the 
> SuperAlgebras[WithBasis] category and do the normal category implementation 
> stuff there.

I disagree.

In a previous post (IIRC), John has emphasised that he is dealing with graded
commutative algebras, which are of course not commutative algebras (indeed,
x*y=-y*x when x,y are of odd degree).

So, it would actually be mathematically wrong to use the axiom "Commutative"
here (in one way or another) because graded commutative algebras are not
commutative, and are thus not sub-categories of CommutativeMonoids (which
would be the effect of using the "Commutative" axiom.

I think the proper way to proceed is: Add a new axiom "GradedCommutative",
that is defined for GradedRings(). Then,
GradedAlgebrasWithBasis(QQ).GradedCommutative() would automatically be
available (as GradedAlgebrasWithBasis(QQ) is a sub-category of
GradedAlgebras(QQ), returning the "Category of graded commutative
graded algebras with basisover Rational Field", and I think that's what
John wanted (if I recall his previous post correctly).

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

[sage-devel] Re: Category help

[Travis Scrimshaw]

>
> Okay, now I have
>
> class SuperCommutativeAlgebrasWithBasis(SuperModulesCategory):
> # Imitating topological_space.py:
> _base_category_class = (SuperAlgebrasWithBasis,)
>
> def example(self, alphabet = ('a','b','c')):
> from 
> sage.categories.examples.super_commutative_algebras_with_basis import 
> Example
> return Example(self.base_ring(), alphabet)
>
> Then I have this problem:
>
> sage: SCAB = SuperCommutativeAlgebrasWithBasis(QQ)
> sage: SCAB.example()
> NotImplemented
>
> Why?
>

That is because of this:

sage: type(SCAB)


Now why that is happening, I do not exactly know. It probably has to do 
with the fact that you do not have a functor construction, e.g., a 
SuperCommutative attribute linking to this class, in 
SuperAlgebrasWithBasis. For instance, in Sets(), there is an attribute 
Topological that links to TopologicalSpaces. There is also a method 
Topological that calls return "TopologicalSpacesCategory.category_of(self)" 
in the SubcategoryMethods so all its subcategories can construct the 
appropriate subcategory, but that is a bit tangential.

IMO, proper way to implement this is as a CategoryWithAxiom as a part of 
SuperAlgebras[WithBasis]. So you add a class 
"Commutative(CategoryWithAxiom_over_base_ring)" to the 
SuperAlgebras[WithBasis] category and do the normal category implementation 
stuff there.

>
> An implementation question: separately from having a category of super 
> commutative algebras, I could imagine wanting the option to use a tensor 
> product of graded algebras which includes a sign in the product:
>
> (x1 tensor y1) (x2 tensor y2) = (-1)^(deg y1 deg x2) (x1 x2 tensor y1 
> y2)
>
> even if neither tensor factor is itself (graded) commutative. How would 
> this be implemented? Define a new tensor product? And then somehow label 
> the category in which the algebra lives to tell it to use that tensor 
> product? Or define an axiom? (Are axioms worth using? I have run into 
> problems with inheritance with axioms.)
>
> This is a bit of a tricky issue. Of course, you could define a new 
TensorProducts category that implements a product_on_basis with this 
version (see AlgebrasWithBasis.TensorProducts.ParentMethods). If the tensor 
product parent was in that category (likely just being a 
CombinatorialFreeModule), then it should work out of the box. I am not sure 
this fits the criteria to be an axiom (but they are definitely worth using 
in the appropriate circumstances). The can of worms comes out when you want 
a natural way to construct that parent in that category. Plus a good name 
will be needed, but I guess the natural place would be part of the 
SuperAlgebras.Commutative.TensorProducts category.

Best,
Travis

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Category help

[John H Palmieri]

On Friday, June 15, 2018 at 7:25:45 PM UTC-7, Travis Scrimshaw wrote:
>
>
> That leads me (or brings me back) to these questions: what is the magic 
>> that is going on, is it documented, and if so, where? If not, there must be 
>> a ticket for writing category documentation, right?
>>
>
> You have to go one further up the hierarchy to the 
> covariant_functorial_construction.py module; at least that is where the 
> main code of the construction is implemented. In particular, the magic 
> import is attempted in _base_category_class. Two examples of what must be 
> done to avoid the magic hook are in topological_spaces.py and homsets.py. 
> Although I agree that the documentation for this is a little lacking here.
>
>>
>> If I look at super_algebras.py, for example, I see
>>
>> class SuperAlgebras(SuperModulesCategory):
>>
>> and not much else. I don't see a lot more in 
>> super_modules.SuperModulesCategory. How is this "doing a functorial 
>> construction," as you put it?
>>
>>  In short, because SuperModulesCategory inherits from 
> CovariantConstructionCategory.
>
> Best,
> Travis
>
>
Okay, now I have

class SuperCommutativeAlgebrasWithBasis(SuperModulesCategory):
# Imitating topological_space.py:
_base_category_class = (SuperAlgebrasWithBasis,)

def example(self, alphabet = ('a','b','c')):
from sage.categories.examples.super_commutative_algebras_with_basis 
import Example
return Example(self.base_ring(), alphabet)

Then I have this problem:

sage: SCAB = SuperCommutativeAlgebrasWithBasis(QQ)
sage: SCAB.example()
NotImplemented

Why?


An implementation question: separately from having a category of super 
commutative algebras, I could imagine wanting the option to use a tensor 
product of graded algebras which includes a sign in the product:

(x1 tensor y1) (x2 tensor y2) = (-1)^(deg y1 deg x2) (x1 x2 tensor y1 
y2)

even if neither tensor factor is itself (graded) commutative. How would 
this be implemented? Define a new tensor product? And then somehow label 
the category in which the algebra lives to tell it to use that tensor 
product? Or define an axiom? (Are axioms worth using? I have run into 
problems with inheritance with axioms.)

-- 
John

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Category help

[Travis Scrimshaw]

> That leads me (or brings me back) to these questions: what is the magic 
> that is going on, is it documented, and if so, where? If not, there must be 
> a ticket for writing category documentation, right?
>

You have to go one further up the hierarchy to the 
covariant_functorial_construction.py module; at least that is where the 
main code of the construction is implemented. In particular, the magic 
import is attempted in _base_category_class. Two examples of what must be 
done to avoid the magic hook are in topological_spaces.py and homsets.py. 
Although I agree that the documentation for this is a little lacking here.

>
> If I look at super_algebras.py, for example, I see
>
> class SuperAlgebras(SuperModulesCategory):
>
> and not much else. I don't see a lot more in 
> super_modules.SuperModulesCategory. How is this "doing a functorial 
> construction," as you put it?
>
>  In short, because SuperModulesCategory inherits from 
CovariantConstructionCategory.

Best,
Travis

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Category help

[John H Palmieri]

On Friday, June 15, 2018 at 2:36:55 AM UTC-7, Travis Scrimshaw wrote:
>
> Hey John,
>
> Okay, so how do I define a new category in Sage? There is some magic 
>> happening somewhere in the category stuff, and I don't know where it's 
>> documented.
>>
>
>> I am in particular interested in creating two categories:
>>
>> - GradedCommutativeAlgebras
>> - GradedCommutativeAlgebrasWithBasis
>>
>> (and then perhaps similarly for coalgebras and Hopf algebras).
>>
>
> Yes, there is some magic going on in order to remove some boilerplate type 
> stuff (in this case, defining the base category). In part, because you are 
> doing a functorial construction, things are a little more complicated. 
> Actually, you will probably want to use the super modules/algebras as your 
> reference, maybe even as your base category. This probably has some of the 
> functionality you want and supercommutative algebras will benefit as well.  
>
> Another question: is the categories primer still accurate? It says (
>> http://doc.sagemath.org/html/en/reference/categories/sage/categories/primer.html#writing-a-new-category
>>  
>> )
>>  
>> that when defining new categories, you have to provide a method 
>> C.super_categories(), but many constructions in the categories directory 
>> (like graded_algebras_with_basis.py) do not explicitly do this.
>>
>
> Yes, it is still implicitly accurate, but the necessity is only about 
> constructing a simple category. If you use an axiom or functorial 
> construction, then these provide a generic super_categories() by magic.
>
> Best,
> Travis
>
>
That leads me (or brings me back) to these questions: what is the magic 
that is going on, is it documented, and if so, where? If not, there must be 
a ticket for writing category documentation, right?

If I look at super_algebras.py, for example, I see

class SuperAlgebras(SuperModulesCategory):

and not much else. I don't see a lot more in 
super_modules.SuperModulesCategory. How is this "doing a functorial 
construction," as you put it?

-- 
John

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Category help

[Travis Scrimshaw]

Hey John,

Okay, so how do I define a new category in Sage? There is some magic 
> happening somewhere in the category stuff, and I don't know where it's 
> documented.
>

> I am in particular interested in creating two categories:
>
> - GradedCommutativeAlgebras
> - GradedCommutativeAlgebrasWithBasis
>
> (and then perhaps similarly for coalgebras and Hopf algebras).
>

Yes, there is some magic going on in order to remove some boilerplate type 
stuff (in this case, defining the base category). In part, because you are 
doing a functorial construction, things are a little more complicated. 
Actually, you will probably want to use the super modules/algebras as your 
reference, maybe even as your base category. This probably has some of the 
functionality you want and supercommutative algebras will benefit as well.  

Another question: is the categories primer still accurate? It says (
> http://doc.sagemath.org/html/en/reference/categories/sage/categories/primer.html#writing-a-new-category
>  
> )
>  
> that when defining new categories, you have to provide a method 
> C.super_categories(), but many constructions in the categories directory 
> (like graded_algebras_with_basis.py) do not explicitly do this.
>

Yes, it is still implicitly accurate, but the necessity is only about 
constructing a simple category. If you use an axiom or functorial 
construction, then these provide a generic super_categories() by magic.

Best,
Travis

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.