-
Notifications
You must be signed in to change notification settings - Fork 189
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
tensor products of abelian groups #2021
Conversation
Signed-off-by: Ali Caglayan <[email protected]>
Signed-off-by: Ali Caglayan <[email protected]>
Signed-off-by: Ali Caglayan <[email protected]>
Signed-off-by: Ali Caglayan <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is looking good so far!
snrapply subgroup_generated. | ||
intros x. | ||
refine ((exists (a1 a2 : A) (b : B), _) + exists (a : A) (b1 b2 : B), _)%type. | ||
- refine (_ - _ - _ = x). | ||
1-3: apply freeabgroup_in. | ||
+ exact (a1 + a2, b). | ||
+ exact (a1, b). | ||
+ exact (a2, b). | ||
- refine (_ - _ - _ = x). | ||
1-3: apply freeabgroup_in. | ||
+ exact (a, b1 + b2). | ||
+ exact (a, b1). | ||
+ exact (a, b2). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess we should have a version of subgroup_generated
that lets you provide a family gen : I -> A
of elements, and constructs the predicate fun x => exists i, gen i = x
for you. Also, I think (a1 + a2, b) - ((a1,b) + (a2,b))
would be the more natural parenthesization. And it might make tensor_dist_* a bit easier. And ab_tensor_prod_rec. In fact, we should probably generalize this to an abelian group with generators and relations, with relations given by two functions I -> A
representing the left and right hand sides of the relations, and a recursion principle in this generality. It should be cleaner.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you expand on this idea a bit further? What would gen
be in this case?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In my first sentence, we could take I
to be A * A * B + A * B * B
and gen
would send (a1,a2,b)
to (a1+a2,b) - ((a1,b) + (a2,b))
and act similarly on the A * B * B
summand.
In my last sentence, I
would stay the same, and we'd have lhs
sending (a1,a2,b)
to (a1+a1,b)
and rhs
sending (a1,a2,b)
to (a1,b) + (a2,b)
(and both would act similarly on the other summand). Then the induction principle would involve an equation, rather than a difference, which might eliminate some of the manipulations needed.
I don't think either thing I'm suggesting saves very much, though, so maybe it's not worth changing.
I like that the twist construction worked well here. I suspect that you can also prove symmetry and the twist using a Yoneda argument, using the universal property and properties of biadditive maps. But the way you've done it is pretty straightforward. |
When we later characterize the universal property as a right adjoint to the internal hom, the Yoneda lemma will play a crucial role in proving things like distributivity over the direct sum. |
Signed-off-by: Ali Caglayan <[email protected]>
Signed-off-by: Ali Caglayan <[email protected]>
Signed-off-by: Ali Caglayan <[email protected]>
Signed-off-by: Ali Caglayan <[email protected]>
Signed-off-by: Ali Caglayan <[email protected]>
Signed-off-by: Ali Caglayan <[email protected]>
Signed-off-by: Ali Caglayan <[email protected]>
Signed-off-by: Ali Caglayan <[email protected]>
The pentagon takes 20 universes or so which isn't ideal. I've been trying to chase down the source of the issue but it seems to be quite systemic throughout the groups library. I think basically any time we use |
I'm hoping that algebraic universes get merged into Coq soon, which I think will get rid of this problem. We'll be able to use |
Well, there are still issues with using It's also great how much simplified by making the free group recursor compute to the expected thing definitionally! What's left to do in this PR? If you think it's ready to merge, let me make one more pass over it before you do. It might be a day or two before I get a chance. |
Signed-off-by: Ali Caglayan <[email protected]>
@jdchristensen I think another pass would be good. Here is a checklist for the remaining issues that I can think of:
|
Signed-off-by: Ali Caglayan <[email protected]>
Signed-off-by: Ali Caglayan <[email protected]>
I wrote a little introduction to the file to explain the tensor product of abelian groups. When I was first learning about tensor products as an undergraduate I struggled with understanding what they are supposed to be useful for. This probably stems from the fact that it is the first "non-canonical" construction defined by a mapping property. Upto then, the way you constructed objects seemed more important and the idea of a universal mapping property was alien. So having something with just a property and no single definition caused a lot of questions marks. I think the punchline that should be kept in mind is that they describe biadditive maps. It seems obvious to us now, but it might help any future readers who are maybe not so familiar with the concept. |
I'm fine with this, but how will we name the simple tensors in the module case? One pattern would be |
I don't yet know what the best names will be once we introduce tensor products of modules, so perhaps the best thing to do would be to rename |
After thinking about it some more, at some point when we start doing calculations with modules we might prefer to work only with R-modules and treat abelian groups as Z-modules in that case. Then it might make sense for the module tensor product to have the name |
Out of curiosity here are the longest lines:
And the entire file is under 1s.
There doesn't appear to be any lines that take longer than they should. |
Signed-off-by: Ali Caglayan <[email protected]>
We can mark However this (only marking as opaque not removing change) has a detrimental effect on the timing of the file, whereby the compilation time goes from 1s to around 1.2s. There is a lot of noise, however the increase appears to be consistent. Also, |
However the naming is done, I think we need some pattern between the abelian group names and the module names. And |
Since it doesn't fix |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've reread the entire diff, and think it looks good!
Signed-off-by: Ali Caglayan <[email protected]>
Signed-off-by: Ali Caglayan <[email protected]>
This PR constructs the tensor product of abelian groups. We show that tensor products give a symmetric monoidal structure to
AbGroup
using the twist construction for symmetric monoidal categories.This PR depends on:
So it would be good to finish those before. In the meantime this PR can be read. There are some issues I would like to address:
ab_tensor_prod
and its constructortensor
are slow to work with. If you have a goal involving them and you do acbn
orsimpl
, Coq will hang. We should think carefully about helping Coq to not unfold certain parts to make this reasonable to work with.TensorProduct.v
needs comments.grp_pow
lemmas should follow from the lemmas outlined in grp_pow and related things #2015.ab_tensor_prod
. We need to think how to share more here.cc @ThomatoTomato as this is something you are presumably interested in.