Cofree Traversable Functors
Total Page:16
File Type:pdf, Size:1020Kb
Load more
Recommended publications
-
Functor Homology and Operadic Homology
FUNCTOR HOMOLOGY AND OPERADIC HOMOLOGY BENOIT FRESSE Abstract. The purpose of these notes is to define an equivalence between the natural homology theories associated to operads and the homology of functors over certain categories of operators (PROPs) related to operads. Introduction The aim of these notes is to prove that the natural homology theory associated to an operad is equivalent the homology of a category of functors over a certain category of operators associated to our operad. Recall that an operad P in a symmetric monoidal category C basically consists of a sequence of objects P(n) 2 C, n 2 N, of which elements p 2 P(n) (whenever the notion of an element makes sense) intuitively represent operations on n inputs and with 1 output: p A⊗n = A ⊗ · · · ⊗ A −! A; | {z } n for any n 2 N. In short, an operad is defined axiomatically as such a sequence of objects P = fP(n); n 2 Ng equipped with an action of the symmetric group Σn on the term P(n), for each n 2 N, together with composition products which are shaped on composition schemes associate with such operations. The notion of an operad is mostly used to define a category of algebras, which basically consists of objects A 2 C on which the operations of our operad p 2 P(n) act. We use the term of a P-algebra, and the notation P C, to refer to this category of algebras associated to any given operad P. Recall simply that the usual category of associative algebras in a category of modules over a ring k, the category of (associative and) commutative algebras, and the category of Lie algebras, are associated to operads, which we respectively denote by P = As; Com; Lie. -
Notes and Solutions to Exercises for Mac Lane's Categories for The
Stefan Dawydiak Version 0.3 July 2, 2020 Notes and Exercises from Categories for the Working Mathematician Contents 0 Preface 2 1 Categories, Functors, and Natural Transformations 2 1.1 Functors . .2 1.2 Natural Transformations . .4 1.3 Monics, Epis, and Zeros . .5 2 Constructions on Categories 6 2.1 Products of Categories . .6 2.2 Functor categories . .6 2.2.1 The Interchange Law . .8 2.3 The Category of All Categories . .8 2.4 Comma Categories . 11 2.5 Graphs and Free Categories . 12 2.6 Quotient Categories . 13 3 Universals and Limits 13 3.1 Universal Arrows . 13 3.2 The Yoneda Lemma . 14 3.2.1 Proof of the Yoneda Lemma . 14 3.3 Coproducts and Colimits . 16 3.4 Products and Limits . 18 3.4.1 The p-adic integers . 20 3.5 Categories with Finite Products . 21 3.6 Groups in Categories . 22 4 Adjoints 23 4.1 Adjunctions . 23 4.2 Examples of Adjoints . 24 4.3 Reflective Subcategories . 28 4.4 Equivalence of Categories . 30 4.5 Adjoints for Preorders . 32 4.5.1 Examples of Galois Connections . 32 4.6 Cartesian Closed Categories . 33 5 Limits 33 5.1 Creation of Limits . 33 5.2 Limits by Products and Equalizers . 34 5.3 Preservation of Limits . 35 5.4 Adjoints on Limits . 35 5.5 Freyd's adjoint functor theorem . 36 1 6 Chapter 6 38 7 Chapter 7 38 8 Abelian Categories 38 8.1 Additive Categories . 38 8.2 Abelian Categories . 38 8.3 Diagram Lemmas . 39 9 Special Limits 41 9.1 Interchange of Limits . -
One-Slide Summary Lecture Outline
Using Design Patterns #1 One-Slide Summary • Design patterns are solutions to recurring OOP design problems. There are patterns for constructing objects, structuring data, and object behavior . • Since this is PL, we’ll examine how language features like (multiple) inheritance and dynamic dispatch relate to design patterns. #2 Lecture Outline • Design Patterns • Iterator • Observer • Singleton • Mediator #3 1 What is a design pattern? • A solution for a recurring problem in a large object-oriented programming system – Based on Erich Gamma’s Ph.D. thesis, as presented in the “gang of four” book • “Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice” – Charles Alexander #4 Types of design patterns • Design patterns can be (roughly) grouped into three categories: • Creational patterns – Constructing objects • Structural patterns – Controlling the structure of a class, e.g. affecting the API or the data structure layout • Behavioral patterns – Deal with how the object behaves #5 Iterator design pattern • Often you may have to move through a collection – Tree (splay, AVL, binary, red-black, etc.), linked list, array, hash table, dictionary, etc. • Easy for arrays and vectors • But hard for more complicated data structures – Hash table, dictionary, etc. • The code doing the iteration should not have to know the details of the data structure -
Arxiv:2010.00369V6 [Math.KT] 29 Jun 2021 H Uco Faeinzto Se[8 H II, Derived Simplicial Ch
ON HOMOLOGY OF LIE ALGEBRAS OVER COMMUTATIVE RINGS SERGEI O. IVANOV, FEDOR PAVUTNITSKIY, VLADISLAV ROMANOVSKII, AND ANATOLII ZAIKOVSKII Abstract. We study five different types of the homology of a Lie algebra over a commutative ring which are naturally isomorphic over fields. We show that they are not isomorphic over commutative rings, even over Z, and study connections between them. In particular, we show that they are naturally isomorphic in the case of a Lie algebra which is flat as a module. As an auxiliary result we prove that the Koszul complex of a module M over a principal ideal domain that connects the exterior and the symmetric powers n n−1 n−1 n 0 → Λ M → M ⊗ Λ M → ⋅⋅⋅ → S M ⊗ M → S M → 0 is purely acyclic. Introduction There are several equivalent purely algebraic definitions of group homology of a group G. Namely one can define it using Tor functor over the group ring; or the relative Tor functor; or in the simplicial manner, as a simplicial derived functor of the functor of abelianization (see [28, Ch. II, §5]). For Lie algebras over a field we can also define homology in several equivalent ways, including the homology of the Chevalley–Eilenberg complex. Moreover, for a Lie algebra g over a commutative ring k, which is free as a k-module we also have several equivalent definitions (see [7, Ch. XIII]). However, in general, even in the case k = Z, these definitions are not equivalent. For example, if we consider g = Z 2 as an abelian Lie algebra over Z, the / Ug Z Z higher homology of the Chevalley–Eilenberg complex vanishes but Tor2n+1 , = Z 2 for any n ≥ 0. -
Object-Oriented Analysis, Design and Implementation
Undergraduate Topics in Computer Science Brahma Dathan Sarnath Ramnath Object-Oriented Analysis, Design and Implementation An Integrated Approach Second Edition Undergraduate Topics in Computer Science Undergraduate Topics in Computer Science (UTiCS) delivers high-quality instruc- tional content for undergraduates studying in all areas of computing and information science. From core foundational and theoretical material to final-year topics and applications, UTiCS books take a fresh, concise, and modern approach and are ideal for self-study or for a one- or two-semester course. The texts are all authored by established experts in their fields, reviewed by an international advisory board, and contain numerous examples and problems. Many include fully worked solutions. More information about this series at http://www.springer.com/series/7592 Brahma Dathan • Sarnath Ramnath Object-Oriented Analysis, Design and Implementation An Integrated Approach Second Edition 123 Brahma Dathan Sarnath Ramnath Department of Information and Computer Department of Computer Science Science and Information Technology Metropolitan State University St. Cloud State University St. Paul, MN St. Cloud, MN USA USA Series editor Ian Mackie Advisory Board Samson Abramsky, University of Oxford, Oxford, UK Karin Breitman, Pontifical Catholic University of Rio de Janeiro, Rio de Janeiro, Brazil Chris Hankin, Imperial College London, London, UK Dexter Kozen, Cornell University, Ithaca, USA Andrew Pitts, University of Cambridge, Cambridge, UK Hanne Riis Nielson, Technical University of Denmark, Kongens Lyngby, Denmark Steven Skiena, Stony Brook University, Stony Brook, USA Iain Stewart, University of Durham, Durham, UK A co-publication with the Universities Press (India) Private Ltd., licensed for sale in all countries outside of India, Pakistan, Bhutan, Bangladesh, Sri Lanka, Nepal, The Maldives, Middle East, Malaysia, Indonesia and Singapore. -
What I Wish I Knew When Learning Haskell
What I Wish I Knew When Learning Haskell Stephen Diehl 2 Version This is the fifth major draft of this document since 2009. All versions of this text are freely available onmywebsite: 1. HTML Version http://dev.stephendiehl.com/hask/index.html 2. PDF Version http://dev.stephendiehl.com/hask/tutorial.pdf 3. EPUB Version http://dev.stephendiehl.com/hask/tutorial.epub 4. Kindle Version http://dev.stephendiehl.com/hask/tutorial.mobi Pull requests are always accepted for fixes and additional content. The only way this document will stayupto date and accurate through the kindness of readers like you and community patches and pull requests on Github. https://github.com/sdiehl/wiwinwlh Publish Date: March 3, 2020 Git Commit: 77482103ff953a8f189a050c4271919846a56612 Author This text is authored by Stephen Diehl. 1. Web: www.stephendiehl.com 2. Twitter: https://twitter.com/smdiehl 3. Github: https://github.com/sdiehl Special thanks to Erik Aker for copyediting assistance. Copyright © 20092020 Stephen Diehl This code included in the text is dedicated to the public domain. You can copy, modify, distribute and perform thecode, even for commercial purposes, all without asking permission. You may distribute this text in its full form freely, but may not reauthor or sublicense this work. Any reproductions of major portions of the text must include attribution. The software is provided ”as is”, without warranty of any kind, express or implied, including But not limitedtothe warranties of merchantability, fitness for a particular purpose and noninfringement. In no event shall the authorsor copyright holders be liable for any claim, damages or other liability, whether in an action of contract, tort or otherwise, Arising from, out of or in connection with the software or the use or other dealings in the software. -
Design Patterns Design Patterns
Design Patterns CSC207 – Software Design Design Patterns • Design pattern: – A general description of the solution to a well- established problem using an arrangement of classes and objects. • Patterns describe the shape of code rather than the details. – There are lots of them in CSC 301 and 302. Loop patterns from first year • Loop pattern: – A general description of an algorithm for processing items in a collection. • All of you (hopefully) have some loop patterns in your heads. • You don’t really need to think about these any more; you just use them, and you should be able to discuss them with your fellow students. • Some first-year patterns: – Process List – Counted Loop – Accumulator – Sentinel Process list pattern • Purpose: to process every item in a collection where you don’t care about order or context; you don’t need to remember previous items. • Outline: • Example: • Other example: darken every pixel in a picture Counted loop pattern • Purpose: to process a range of indices in a collection. • Outline: • Example: • Other example: print indices of even-length string Accumulator pattern • Purpose: to accumulate information about items in a collection. • Outline: • Example: • Other examples: sum, min, accumulate a list of items meeting a particular criterion. Sentinel pattern • Purpose: to remove a condition in a loop guard. • Outline: • Example: Sentinel pattern, continued • Here is the code that Sentinal replaces; note that i != list.size() is evaluated every time through the loop, even though it is false only once. Design Pattern -
On Iterated Semidirect Products of Finite Semilattices
View metadata, citation and similar papers at core.ac.uk brought to you by CORE provided by Elsevier - Publisher Connector JOURNAL OF ALGEBRA 142, 2399254 (1991) On Iterated Semidirect Products of Finite Semilattices JORGE ALMEIDA INIC-Centro de Mawmdtica, Faculdade de Ci&cias, Universidade do Porro, 4000 Porte, Portugal Communicated by T. E. Hull Received December 15, 1988 Let SI denote the class of all finite semilattices and let SI” be the pseudovariety of semigroups generated by all semidirect products of n finite semilattices. The main result of this paper shows that, for every n 2 3, Sl” is not finitely based. Nevertheless, a simple basis of identities is described for each SI”. We also show that SI" is generated by a semigroup with 2n generators but, except for n < 2, we do not know whether the bound 2n is optimal. ‘(” 1991 Academic PKSS, IW 1. INTRODUCTION Among the various operations which allow us to construct semigroups from simpler ones, the semidirect product has thus far received the most attention in the theory of finite semigroups. It plays a special role in the connections with language theory (Eilenberg [S], Pin [9]) and in the Krohn-Rodes decomposition theorem [S]. Questions dealing with semidirect products of finite semigroups are often properly dealt with in the context of pseudovarieties. For pseudovarieties V and W, their semidirect product V * W is defined to be the pseudovariety generated by all semidirect products S * T with SE V and T E W. It is well known that this operation on pseudovarieties is associative and that V * W consists of all homomorphic images of subsemigroups of S * T with SE V and TEW [S]. -
Lie-Butcher Series, Geometry, Algebra and Computation
Lie–Butcher series, Geometry, Algebra and Computation Hans Z. Munthe-Kaas and Kristoffer K. Føllesdal Abstract Lie–Butcher (LB) series are formal power series expressed in terms of trees and forests. On the geometric side LB-series generalizes classical B-series from Euclidean spaces to Lie groups and homogeneous manifolds. On the algebraic side, B-series are based on pre-Lie algebras and the Butcher-Connes-Kreimer Hopf algebra. The LB-series are instead based on post-Lie algebras and their enveloping algebras. Over the last decade the algebraic theory of LB-series has matured. The purpose of this paper is twofold. First, we aim at presenting the algebraic structures underlying LB series in a concise and self contained manner. Secondly, we review a number of algebraic operations on LB-series found in the literature, and reformulate these as recursive formulae. This is part of an ongoing effort to create an extensive software library for computations in LB-series and B-series in the programming language Haskell. 1 Introduction Classical B-series are formal power series expressed in terms of rooted trees (con- nected graphs without any cycle and a designated node called the root). The theory has its origins back to the work of Arthur Cayley [5] in the 1850s, where he realized that trees could be used to encode information about differential operators. Being forgotten for a century, the theory was revived through the efforts of understanding numerical integration algorithms by John Butcher in the 1960s and ’70s [2, 3]. Ernst Hairer and Gerhard Wanner [15] coined the term B-series for an infinite formal se- arXiv:1701.03654v2 [math.NA] 27 Oct 2017 ries of the form H. -
Free Split Bands Francis Pastijn Marquette University, [email protected]
Marquette University e-Publications@Marquette Mathematics, Statistics and Computer Science Mathematics, Statistics and Computer Science, Faculty Research and Publications Department of 6-1-2015 Free Split Bands Francis Pastijn Marquette University, [email protected] Justin Albert Marquette University, [email protected] Accepted version. Semigroup Forum, Vol. 90, No. 3 (June 2015): 753-762. DOI. © 2015 Springer International Publishing AG. Part of Springer Nature. Used with permission. Shareable Link. Provided by the Springer Nature SharedIt content-sharing initiative. NOT THE PUBLISHED VERSION; this is the author’s final, peer-reviewed manuscript. The published version may be accessed by following the link in the citation at the bottom of the page. Free Split Bands Francis Pastijn Department of Mathematics, Statistics and Computer Science, Marquette University, Milwaukee, WI Justin Albert Department of Mathematics, Statistics and Computer Science, Marquette University, Milwaukee, WI Abstract: We solve the word problem for the free objects in the variety consisting of bands with a semilattice transversal. It follows that every free band can be embedded into a band with a semilattice transversal. Keywords: Free band, Split band, Semilattice transversal 1 Introduction We refer to3 and6 for a general background and as references to terminology used in this paper. Recall that a band is a semigroup where every element is an idempotent. The Green relation is the least semilattice congruence on a band, and so every band is a semilattice of its -classes; the -classes themselves form rectangular bands.5 We shall be interested in bands S for which the least semilattice congruence splits, that is, there exists a subsemilattice of which intersects each -class in exactly one element. -
Applicative Programming with Effects
Under consideration for publication in J. Functional Programming 1 FUNCTIONALPEARL Applicative programming with effects CONOR MCBRIDE University of Nottingham ROSS PATERSON City University, London Abstract In this paper, we introduce Applicative functors—an abstract characterisation of an ap- plicative style of effectful programming, weaker than Monads and hence more widespread. Indeed, it is the ubiquity of this programming pattern that drew us to the abstraction. We retrace our steps in this paper, introducing the applicative pattern by diverse exam- ples, then abstracting it to define the Applicative type class and introducing a bracket notation which interprets the normal application syntax in the idiom of an Applicative functor. Further, we develop the properties of applicative functors and the generic opera- tions they support. We close by identifying the categorical structure of applicative functors and examining their relationship both with Monads and with Arrows. 1 Introduction This is the story of a pattern that popped up time and again in our daily work, programming in Haskell (Peyton Jones, 2003), until the temptation to abstract it became irresistable. Let us illustrate with some examples. Sequencing commands One often wants to execute a sequence of commands and collect the sequence of their responses, and indeed there is such a function in the Haskell Prelude (here specialised to IO): sequence :: [IO a ] → IO [a ] sequence [ ] = return [] sequence (c : cs) = do x ← c xs ← sequence cs return (x : xs) In the (c : cs) case, we collect the values of some effectful computations, which we then use as the arguments to a pure function (:). We could avoid the need for names to wire these values through to their point of usage if we had a kind of ‘effectful application’. -
Singleton ● Iterator
CSC207 Week 6 Larry Zhang 1 Logistics ● Midterm: next Friday (October 27), 5:10 PM - 7:00 PM ● 110 minutes ● No aid ● Room: TBA (Note it’s not the lecture room) ● Past tests posted on the course website: http://axiom.utm.utoronto.ca/~207/17f/tests.shtml ● Arnold will send emails with more info. 2 Design Patterns 3 /r/LifeProTips 4 Design Patterns Design patterns are like “LifeProTips” for software design. ● Effective use of the OO Paradigm. ● Using the patterns results in flexible, malleable, maintainable code. ● It usually allows plug and play additions to existing code. ● It gives developers a vocabulary to talk about recurring class organizations. 5 Design Patterns for Today ● Observer ● Singleton ● Iterator 6 The Observer Pattern 7 Goals ● When certain objects need to be informed about the changes occurred in other objects. ● One object changes state, all its dependents are notified and updated automatically. ● Programmer only need to worry about how the observer changes if the observables changes, and connecting the observers and observables. ● Real-life example: setting up Pre-Authorized Bill Payment 8 General Implementation 9 Java Implementation 10 DEMO #1 Implement Our Own Observer/Observable observer/Observable.java observer/Observer.java 11 DEMO #2 Use Our Observer/Observable observer/LightBulb.java observer/LightBulbObserver.java observer/LightBulbObservable.java observer/LightBulbMain.java 12 Advanced Issues in Observer Pattern Push and Pull communication methods ● Push model: the Observable send all information about the change