日常生活の問題のモデリングで制限と制限の概念をどのように使用できるかを知りたいのですが?(ソフトウェア)エンジニアリングの例を誰か提供してもらえますか?または、これらの概念を使用できるモデリング問題の種類について、一般的に直感的に説明しますか?ありがとうございました。
日常生活の問題のモデリングで制限と制限の概念をどのように使用できるかを知りたいのですが?(ソフトウェア)エンジニアリングの例を誰か提供してもらえますか?または、これらの概念を使用できるモデリング問題の種類について、一般的に直感的に説明しますか?ありがとうございました。
回答:
良い例は、Tate et al。のProofsからのGenerating Compiler Optimizationsです。彼は、矢印が(IIRC)置換であるカテゴリーで、一般化された共用体および交差としてプルバックとプッシュアウトを使用しています。
Ross Tateは(紙のWebページで)カテゴリ理論による抽象化がなければ詳細は圧倒的であると主張しています。個人的に、私は「示唆的証拠」として(そのような主張の証拠があり得る場合)図表(6)と(7)として提出したいと思います。コメントをインラインで引用させてください。
一部の人々は、なぜ証明汎化手法をまったく抽象化したのか、なぜ抽象化としてカテゴリー理論を使用したのかと尋ねてきました。ただし、実際には、まずカテゴリー理論を使用して抽象アルゴリズムを設計し、次にそれを使用して具体的な問題を解決する方法を理解しました。私たちは具体的な問題に行き詰まり、詳細と変数に圧倒され、考えられる解決策は恣意的であるように見えました。反映し簡略化するために、質問を明確に表現することにしました。これはソースとシンクの図につながるので、プッシュアウトとプルバックを使用して物事を接着しました。最大の課題は、既存の標準コンセプトを使用するのではなく、プッシュアウト補完を考案することでした。カテゴリカルな定式化は、簡単に指定でき、推論することができました。その後、抽象的なプロセスをインスタンス化し、
私たちは実際に立ち往生するたびに、カテゴリー理論に抽象化するこのプロセスが実り多いことに気づきました。それは最終的に私たちの具体的な問題を解決するだけでなく、私たち自身の問題と、他のアプリケーションに簡単に適応できる抽象的な解決策をよりよく理解することになります。したがって、私たちの経験は、カテゴリー化理論は、形式化のフレームワークとして役立つだけでなく、実際のアルゴリズムの構築にも役立つ可能性があることを示唆しています。私達は他の同様の経験を知りたいと思っています。
でスピヴァクの本 192ページ彼が作成するcolimitsの使用例与え路線図を。また、彼のApplication 5.2.1.2は、Liquibaseのようなパッチをデータベーススキーマに時間をかけて適用し、共通制限を使用して古いデータと新しいデータを普遍的な方法で推論することについて説明しています。
アプリケーションの幅広い分野は、グラフ変換(モデル駆動型エンジニアリングに適用)です。関連する論文は2つあります(Google Scholarへのリンクが提供されています)。
編集:繰り返しになりますが、基本的な考え方は、プッシュアウトは接着剤との結合として機能するということです。これにより、グラフの「書き換え規則」を定義できます。左側をグラフに一致させ、右側を対応する方法で(残りの)グラフに接着します。直感以上に得たことがないので、詳細を追加することはできません。