매일 문제에서 범주 이론의 한계와 공동 한계의 용도는 무엇입니까?

일상 생활에서 문제를 모델링하는 데 한계와 Colimits 개념을 어떻게 사용할 수 있는지 알고 싶습니다. 누구나 (소프트웨어) 엔지니어링 예제를 제공 할 수 있습니까? 또는 이러한 개념을 사용할 수있는 모델링 문제에 대해 일반적으로 직관적으로 설명 하시겠습니까? 감사합니다.

어떤 관계를 가지십시오 $R_0\subseteq A_0\times A_1$, $R_1\subseteq A_1\times A_2$. 허락하다$\pi_1:R_0\to A_1$, $\pi_0:R_1\to A_1$ 관계가 제한된 영역을 가진 계획이다 $R_0$, $R_1$. 그런 다음 풀백$\pi_0$, $\pi_1$ 의 조인 $R_0$ 과 $R_1$ SQL 의미에서.

좋은 예는 Tate et al.의 Proofs 에서 생성하는 컴파일러 최적화입니다 . 화살표가 (IIRC) 대체 인 범주에서 풀백 및 푸시 아웃을 일반화 된 유니온 및 교차로로 사용합니다.

Ross Tate는 (종이 웹 페이지에서) 범주 이론에 의한 추상화없이 세부 사항이 압도적이라고 주장합니다. 개인적으로 저는 논문에 "추천 적 증거"(그러한 주장의 증거가있을 수있는 경우) 다이어그램 (6, 7)으로 제출하고 싶습니다. 그들의 의견을 인라인으로 인용하겠습니다.

일부는 우리가 왜 증명 일반화 기술을 추상화했는지, 왜 우리는 카테고리 이론을 추상화로 사용했는지 묻습니다. 그러나 카테고리 이론을 사용하여 추상 알고리즘을 먼저 디자인 한 다음 구체적인 문제를 해결하는 방법을 알아 냈습니다. 세부 사항과 변수, 그리고 우리가 생각할 수있는 모든 솔루션에 압도 된 구체적인 문제에 갇혔습니다. 반영하고 단순화하기 위해 우리는 질문을 범주 적으로 표현하기로 결정했습니다. 이로 인해 소스 및 싱크 다이어그램이 생성되었으므로 푸시 아웃 및 풀백을 사용하여 사물을 서로 붙입니다. 가장 큰 과제는 기존의 표준 개념을 사용하는 대신 푸시 아웃을 완료하는 것이 었습니다. 범주 형 공식은 쉽게 정의하고 추론 할 수있었습니다. 그런 다음 추상 프로세스를 인스턴스화했습니다.

우리는 실제로 결실을 맺을 때마다 범주 이론으로 추상화하는이 과정을 발견했습니다. 구체적인 문제를 해결할뿐만 아니라 다른 문제에 쉽게 적용 할 수있는 추상 솔루션뿐만 아니라 우리 자신의 문제를 더 잘 이해하게됩니다. 따라서 우리의 경험에 따르면 범주 이론은 공식화를위한 프레임 워크로 유용 할뿐만 아니라 실제 알고리즘을 구성하는 데 유용 할 수 있습니다. 우리는 긍정적이거나 부정적인 다른 유사한 경험을 알고 자합니다.

에서 Spivak의 책 192 페이지에 그는 만들 colimits를 사용하는 예를 제공 노선도를 . 또한 그의 Application 5.2.1.2에서는 Liquibase 와 같은 패치를 데이터베이스 스키마에 시간이 지남에 따라 적용한 다음 공통 한계를 사용하여 기존 데이터와 새 데이터를 공통 방식으로 추론합니다.

광범위한 응용 분야는 그래프 변환 (모델 중심 엔지니어링에 적용)에 있습니다. 두 가지 관련 논문이 있습니다 (Google Scholar 링크가 제공됨).

• 그래프 변환에 대한 자습서 소개 : 소프트웨어 엔지니어링 관점
• 그래프 변환-파트 I에 대한 대수적 접근 : 기본 개념 및 이중 푸시 아웃 접근.

편집 : 다시, 기본 아이디어의 일부는 푸시 아웃이 접착제와의 결합 역할을한다는 것입니다. 이를 통해 그래프의 "다시 쓰기 규칙"을 정의 할 수 있습니다. 왼쪽을 그래프와 일치시킨 다음 오른쪽을 해당하는 방식으로 그래프의 나머지 부분에 붙입니다. 직관 이상을 얻지 못했기 때문에 세부 정보를 추가 할 수 없습니다.