You're reading the public-facing archive of the Category Theory Zulip server.
To join the server you need an invite. Anybody can get an invite by contacting Matteo Capucci at name dot surname at gmail dot com.
For all things related to this archive refer to the same person.
I'm trying to understand the definition of a grate in the Profunctor optics: a categorical update paper (Proposition 3.31).
Namely, the variances of the monoidal actions used here seem to be wrong. If I look at the 2nd line of the isomorphism in the screenshot, I see the that variable bound in the coend is used twice, but both times with the same variance. However, a coend requires bivariance.
Screenshot_20210524_170902.png
How do I understand this?
Comparing Def 3.30 to the type signature above it, I guess Def 3.30 is wrong (the should be some kind of cotensor, contravariant in the argument)...?
Hmm, I suppose so. I'll have to unpack what this really means. Even with this information, it's kind of strange to see both 's appear on the left side of the hom...
On second thought, I'm not sure if that's correct, @Reid Barton . For instance, take a look at Prop. 3.2 in the same paper which defines Lenses.
Screenshot_20210524_180734.png
They use two covariant functors in two variables. One would think that's wrong as well, but I now think that that the actual contravariance in the first line of the coend arises as follows.
The functor is contravariant, and what happens is that we first apply to to get a functor which we then "op", i.e. we take and plug it into the functor at the beginning of this paragraph.
Does that seem reasonable?
If so, then I am still pretty confused about the flow of information in a grate, and the lack of explicit variance in the paper isn't helping.
I agree 3.2 is fine.
But the types of a lens corresponding to Def 3.1 would be something like get :: s -> a, set :: (s, b) -> t
. So here seems to correspond to pairing (which makes sense, as it's covariant in both arguments). Whereas in the grates section, an arrow appears instead in ((s -> a) -> b) -> t
--I mean the one between s -> a
and b
.
I'll think about what you posted, but in the meantime I'll post what I started writing:
I really don't know how to interpret the flow of information in grates causally. Maybe it helps if I write down how I think of lenses/prisms.
In lenses, we take an input, then save a state and produce an output. When we get a result from the environment, we use it and the state we saved to produce an update.
In prisms, we take an input, then save a state or produce an output (i.e. query the environment). Depending on what we did, we either use an output from the environment or the saved state.
But in grates, I don't know what the story is. (the short description in the paper does not really help)
Reid Barton said:
But the types of a lens corresponding to Def 3.1 would be something like
get :: s -> a, set :: (s, b) -> t
. So here seems to correspond to pairing (which makes sense, as it's covariant in both arguments). Whereas in the grates section, an arrow appears instead in((s -> a) -> b) -> t
--I mean the one betweens -> a
andb
.
Are you saying the is also something like an exponential? This is pretty strange, especially since they don't refer it in the paper as such:
Screenshot_20210524_183648.png
i.e. they call the other thing the exponential, but not .
Also, since the exponential of has type , the first argument of also has to live in to match the general notion of an optic (2.1).
could be the exponential for example if .
It would be unusual to use a multiplication-like symbol like for an exponential/cotensor type operation though. So I'm guessing there was some kind of confusion on the author's side.
I haven't heard of grates before either, so I can't help you there.
In the programming sense of grates, ((s -> a) -> b) -> t
can be read as “having a function giving an element b
for a given accessor (s -> a)
produces a new container t
”. The idea is the accessors (s -> a)
index the (fixed number of) positions in the container whose shape is shared by s
and t
. These end up having to be representable functors, I believe, because they are containers with a fixed shape. I’m not familiar with the categorical interpretations of optics I’m afraid.
https://r6research.livejournal.com/28050.html
Reid Barton said:
It would be unusual to use a multiplication-like symbol like for an exponential/cotensor type operation though. So I'm guessing there was some kind of confusion on the author's side.
Perhaps someone from the profunctor gang can help us here? @Bryce Clarke , @fosco, @Mario Román, @Emily Pillmore ?
Nick Scheel said:
Thanks! This is one of those blog posts I've seen before, but they are very hard to understand for me...
Assume (thus ). Assume we choose a representative for a grate . The view part is a map , while is a map .
I can think of the view part as returning a bunch of s ( :bee: ), a bunch indexed by . Then the update takes in an and a . One can use the to access a , using the map returned by . Then you have a and a and you can do your thing to get an
This also shows that is useless, since it can always be shortcut by evaluation. Indeed, the coend reduction shows that I can always assume , basically, so that the update receives a map and a . Then it evaluates with the state coming from outside, and finally gets its .
So maybe an intuition for this is that the computation of is deferred: I never actually return to the environment, and I first ask for a continuation . Once I have it, I compute and I go on with the second part of the computation.
This prevents the environment from yielding a continuation that actually depends on , I think.
(I apologise for using a notational convention which probably different than everyone's here, certainly different from the categorical update paper)
I think this is what a grate looks like in string diagrams of closed categories:
which is admittedly quite bad
Thanks Matteo! This is very helpful.
Matteo Capucci (he/him) said:
I can think of the view part as returning a bunch of s ( :bee: ), a bunch indexed by . Then the update takes in an and a . One can use the to access a , using the map returned by . Then you have a and a and you can do your thing to get an
Hmm, so I am stuck here. "Then the update takes in a ". Where does that come from? Unlike with lenses or prisms, here in the forward pass we do not produce an , but rather we produce a thing that takes in a .
On that note, I'm not sure how to think of reparameterizations here. Say that your map is actually a composite where and
Then, since this is an optic, I expect to be able to slide that over to the forward pass and plug it into something that creates that . But there's no such thing: the only thing created in the forward pass is .
So this seems related to the question of variance from before, and I don't see a way how this can work.
Bruno Gavranovic said:
Thanks Matteo! This is very helpful.
Matteo Capucci (he/him) said:
I can think of the view part as returning a bunch of s ( :bee: ), a bunch indexed by . Then the update takes in an and a . One can use the to access a , using the map returned by . Then you have a and a and you can do your thing to get an
Hmm, so I am stuck here. "Then the update takes in a ". Where does that come from? Unlike with lenses or prisms, here in the forward pass we do not produce an , but rather we produce a thing that takes in a .
Yeah, there's no coming around. But if it comes around we can do that. I know, it's a bit shaky :~
Bruno Gavranovic said:
On that note, I'm not sure how to think of reparameterizations here. Say that your map is actually a composite where and
Then, since this is an optic, I expect to be able to slide that over to the forward pass and plug it into something that creates that . But there's no such thing: the only thing created in the forward pass is .
So this seems related to the question of variance from before, and I don't see a way how this can work.
The action of such an on the forward part is , given by precomposition. So sliding here means that and , I think.
Yesterday @Matteo Capucci (he/him) and me had some discussions in private and I think we concluded that this definition makes sense only when , otherwise the variances do not line up.
I'll just respond to the last message for completeness, to write some arguments I said.
Matteo Capucci (he/him) said:
Yeah, there's no coming around. But if it comes around we can do that. I know, it's a bit shaky :~
This really does not align with how I see optics: we need to say where the comes from. This is where the bivariance of the coend comes in.
Matteo Capucci (he/him) said:
The action of such an on the forward part is , given by precomposition. So sliding here means that and , I think.
This can be unpacked and it can be seen that there's no sliding happening here. To get the usual optic equivalence relation, we need just one equation, of the form where appears once on the left side, and once on the right.
@Bruno Gavranovic. I think this is just missing an op in the action .
This way, you have two actions from a common category, . The coend computation remains unaltered.
I am quite sure I introduced that typo on the paper, so thank you very much for bringing this to my attention (please, do feel free to also email me for these :) I almost never open Zulip). As @Reid Barton said, using the bullet to denote a contravariant action is particularly confusing. I probably got confused when trying to copy the style of the rest of the definitions. In the previous "Profunctors and Traversals" the contravariance is right, so I must have introduced it when preparing the second paper.
The op will be added in the next version, the bullet will be changed to a more explanatory symbol. Thanks to both again!
Ah, I was just thinking about this last night! Thanks, I'll have a look!
Mario Román said:
The op will be added in the next version, the bullet will be changed to a more explanatory symbol. Thanks to both again!
It's good to know that there's a next version planned. I'm looking forward to reading it
@Mario Román I am still confused about what grates do. I'm trying to compare them to lenses or prisms. If I take the the coend representation of a lens , and think of it operationally, it tells me that I take in an , produce an and an , and then when receiving a , I take the previously produced too and use it to construct a .
But for grates, it seems that the first map doens't produce the residual , it waits for it as an input (via the tensor hom adjunction). Is that correct? If the first map is waiting for an input , that must mean that the second map produces it, and all-together it means that the operational view of a grate is different than that of a lens or a prism, since the information flows from the second map to the first.
Is what I'm saying correct?
All I'm trying to really do is have an operational, causal view of what a grate does. I.e. "where do I start", "what do I do" and "where do I end up". With lenses/prisms I start at , (always/possibly) use it construct the residual, and end up at . But with grates it seems different
Bruno Gavranovic said:
Mario Román I am still confused about what grates do. I'm trying to compare them to lenses or prisms. If I take the the coend representation of a lens , and think of it operationally, it tells me that I take in an , produce an and an , and then when receiving a , I take the previously produced too and use it to construct a .
But for grates, it seems that the first map doens't produce the residual , it waits for it as an input (via the tensor hom adjunction). Is that correct? If the first map is waiting for an input , that must mean that the second map produces it, and all-together it means that the operational view of a grate is different than that of a lens or a prism, since the information flows from the second map to the first.
Is what I'm saying correct?
Sort of, yes. Although it is confusing for me to say that the second part of the optic produces that C. I think what you are saying describes a particular kind of grate where the second action is the left adjoint to the tensor: Lenses Flowing Back.
I can try to give an operational description of grates saying that they aggregate foci: Operational View of Grates. And if you want to see them as dual to lenses, the Van Laarhoven representation kind of says that: Van Laarhoven Lenses and Grates.
Yeah the Van Laarhoven representation helped me a lot to understand what grates do
Also the fact they are morphisms of 'Naperian containers', i.e. containers with a fixed shape. Together with the fact that , and combine to give polynomials, hence containers, made me realize grates are kind of degenerate dependent lenses
Grates are pretty mysterious! But becoming less so by the moment. Thanks @Mario Román for writing this up, it's immensely helpful.
I've got many thoughts about this, but I'll just give short remarks now and hopefully write something more concrete later.
And if you want to see them as dual to lenses
Prisms are often to considered "dual" of lenses. I suppose this is a "different duality". Prisms seem to be dual in what they do compared to lenses (+ instead of x), but how would you describe the grate duality?
the Van Laarhoven representation kind of says that: Van Laarhoven Lenses and Grates.
I find the remark about zipping interesting, but a bit confusing. Don't lenses also allow us to unzip? If we have a map , we surely ought to be able to turn it to a map ?
Prisms are often to considered "dual" of lenses. I suppose this is a "different duality". Prisms seem to be dual in what they do compared to lenses (+ instead of x), but how would you describe the grate duality?
is dual to as in 'reversing arrows' whereas exponentials are dual to as in 'right adjoint'
Wouldn't the right adjoint of give us linear lenses?
No, linear lenses are the same thing as lenses, just a different presentation that's possible when closed structure is around
Instead grates arise from using the closed structure as one of the actions itself
Right, that makes sense
is it correct to say that grates represent the "powerhood" of an object? if so, is there some name for the analogous optic that represents the "copowerhood" of an object?
in the case of both M = C = D = Set i believe this degenerates to the hom functor, which is perhaps what @Verity Scheel was pointing to