categories - Category Theory list
 help / color / mirror / Atom feed
From: Richard Garner <richard.garner@mq.edu.au>
To: John Baez <baez@math.ucr.edu>, categories <categories@mta.ca>
Subject: Re: categories of models of cartesian PROPs
Date: Thu, 20 Aug 2015 10:28:19 +1000	[thread overview]
Message-ID: <E1ZSUsy-0005Lh-8t@mlist.mta.ca> (raw)
In-Reply-To: <E1ZS3A0-00051h-Q0@mlist.mta.ca>

Dear John,

Caveat lector - this is all rather off the cuff so there may be some
mistakes in what follows:

> Suppose you have a category with finite products, say T, and a symmetric
> monoidal category, say C.   Let [T,C] be the category where
>
>     objects are symmetric monoidal functors from T to C,
>     morphisms are monoidal natural transformations.
>
> *1.  What structure beyond a mere category does [T,C] automatically get
> in
> this sort of situation?*
>
> I haven't thought about this much.  Even if T were just symmetric
> monoidal,
> I think [T,C] should get a symmetric monoidal structure due to "pointwise
> multiplication", just as the set of homomorphisms from one commutative
> monoid to another becomes a commutative monoid where
>
> fg(x) := f(x) g(x)
>
> Should [T,C] also have some sort of "comultiplication"?  What extra
> benefits do we get from T being cartesian?

Yes, this pointwise structure exists; it's part of a monoidal bicategory
structure on the 2-category of symmetric monoidal closed categories and
symmetric strong monoidal functors. More generally if T is any symmetric
pseudomonoidal 2-monad on Cat, then the 2-category of T-algebras and
strong morphisms is a monoidal bicategory; see:

Hyland, Power "Pseudo-commutative monads and pseudo-closed 2-categories"
(2002)

In the case you describe it seems that this pointwise structure on
StrMon[T,C] is actually cartesian. The point is that, since each t in T
is a cocommutative comonoid naturally in T, if F: T--->C is strong
monoidal, then each Ft is a cocommutative comonoid, naturally in T. But
this means that we have maps F ---> F * F for the pointwise tensor
product on StrMon[T,C], making it into a cocommutative comonoid therein.
Since these maps are actually natural in F, each object of StrMon[T,C]
is naturally a cocommutative comonoid, so that the monoidal structure
must be cartesian. There's some details I haven't checked here, because
various things need to be strong monoidal functors and transformations,
but my immediate impression is that all this should work.

> *2.  What further structure do we get if C has some particular class of
> limits or colimits?*

For any symmetric monoidal T, it's easy to see that LaxMon[T,C] will
inherit any pointwise limits existing in the mere functor category
[T,C]. Likewise OplaxMon[T,C] will inherit any colimits. In order for
some class of these pointwise limits or colimits to restrict back to
StrMon[T,C], it seems that what you need is for the tensor functor C x C
----> C and the unit functor I:1---->C to preserve limits or colimits in
that class.

In particular, if C had filtered colimits or reflexive coequalisers (or
more generally any kind of sifted colimit) and these were preserved by
the tensor product functor in each variable separately (which would
happen if, for example, C were symmetric monoidal closed) then you could
deduce that, actually, C x C ---> C and 1 ---> C preserved them, and so
conclude that StrMon[T,C] had filtered colimits / reflexive coequalisers
computed pointwise.

Dually, if C had coreflexive equalisers preserved by tensor in each
variable (for example, if C = Vect) then StrMon[T,C] would again have
pointwise coreflexive equalisers. In particular, if T is cartesian, so
that we have finite products given by the pointwise tensor product, then
in this case we have all finite limits.

Richard


[For admin and other information see: http://www.mta.ca/~cat-dist/ ]


  reply	other threads:[~2015-08-20  0:28 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-17  8:14 John Baez
2015-08-20  0:28 ` Richard Garner [this message]
2015-08-21  4:23   ` John Baez
2015-08-22  1:49     ` John Baez
2015-08-23 14:09       ` Fabio Gadducci
2015-08-20 20:20 ` Aleks Kissinger
2015-08-19 19:31 Fred E.J. Linton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=E1ZSUsy-0005Lh-8t@mlist.mta.ca \
    --to=richard.garner@mq.edu.au \
    --cc=baez@math.ucr.edu \
    --cc=categories@mta.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).