Обсуждение

Да, но есть двойственное копределу понятие предела - это когда nothing more to add. Обычно поведение систем двойственно. Поведение комнаты с часами (плюс хаос за пределами комнаты) менее разнообразно чем поведение хаоса с часами.

Ага, такая вот "диалектика". )) Вот нужно научиться как-то об этом рассказывать простыми словами, нематематическими. Я подумал, что обрывки этого понимания предела-копредела есть во многих дисциплинах, которые связаны с моделированием. Так в НЛП задают вопрос "где та разница, которая делает разницу?" -- изо всего разнообразия внешних проявлений что моделировать, что имеет отношение к делу и поэтому участвует в изменении? То есть нужно найти такие элементы, трансформация которых меняет искомую эмерджентность -- не меньше этих элементов (полнота, предел), но и не больше (совершенство, копредел).

Нематематически пока нельзя. "Не родился еще тот богатырь". Дело в том, что эти "nothing more to add" и "nothing more to remove" - лишь малюсенький частный случай реальной выразительной мощи ТК. Именно по этому я никогда не мог объяснить чем ТК так хороша - мне не хватало этой продуктивной "наглости" обрезать и приглушить ее реальное богатство содержания так, чтобы стало понятно. А Сергею хватило, честь ему и хвала за это.

Иными словами, чтобы понять насколько реально мощны предельные понятия ТК, нужно решать специально подобранные задачки из разных областей математики. Иначе не ухватишь её междисциплинарность за хвост и будет оставаться вопрос "ну и что?". Другого способа пока не придумали (не родился еще тот богатырь). Вся классика учебников ТК действует таким способом.

Это общеизвестный факт: чем больше разнообразие, тем сложней творить. Из хаоса мало что можно построить ценного -- но потенциально-то всё, что сильно смущает! Белым стихом мало кто пишет, он без правил. А вот какие-нибудь сонеты или гекзаметр -- получается гениально. Из транзисторов на чипе можно сочинить потенциально любой процессор, но реально сочиняют только для наиболее употребимых машинных команд -- остальные потенциально полезные для выполнения программы машинные команды так и остаются нереализованными в "железе". В системной инженерии потенциально любые viewpoints. Но когда начинаешь разбираться, то лучше контролировать наличие компонент и коннекторов, модулей и интерфейсов, размещений -- а остальное "по потребности". То же самое: нужно всю мощь ТК конкретизировать до наиболее употребимых ситуаций, а остальное -- всегда можно вернуться в более общую математику, этого никто не запрещает. Меня интересует как раз приложение ТК для системного подхода в его варианте для системной инженерии. Мы это говорили на заседании INCOSE: что-то меньшее, чем теория категорий, но большее чем upper ontology типа 201 типа ISO 15926. Договорились называть это technical space-штрих, вслед за терминологией группы AtlanMod (то есть это язык, на котором можно писать классические онтологии, грамматики, алгоритмы и т.д. -- более общий чем они все, но менее общий, чем вся математика в целом). В общем, место мутное, нужно разбираться.

Мой ход совсем другой: я выделяю "средний уровень" (системное мышление), от которого можно идти "вверх" в философию-математику и "вниз" в моделирование в конкретных инженерных практиках, с конкретными языками моделирования и софтом САПР разного вида. Чтобы показать мощь ТК, на мой взгляд нужно решать не математические задачки из разных областей математики, а решать инженерные задачки -- точно так же, как в школах мощь математики показывают сначала на уроках арифметики, решая задачки типа "две собаки грызут колбасу с разных сторон и приканчивают её за 4 минуты, одна из собак сгрызает всю колбасу за 12 минут. Сколько времени потратит..." -- вместо того, чтобы объяснять деткам сложнейшие теоремы теории чисел и выводить понятие пропорции из общих принципов. И даже в этом случае есть проблема не столько проблем уходить от этих задач к общематематической проблематике, сколько переносить навык работы с пропорциями и простыми арифметическими расчётами в реальную жизнь (грубо говоря, переносить опыт подсчёта яблок из задачи на подсчёт реальных яблок из жизни).

>>Чтобы показать мощь ТК, на мой взгляд нужно решать не математические задачки из разных областей математики, а решать инженерные задачки Вот вот, я об этом же! Только для этого нужно сначала построить инженерные категории, а для этого нужен софт. >>И даже в этом случае есть проблема не столько проблем уходить от этих задач к общематематической проблематике Я очень хочу чтобы был понятен тезис - ТК это ни разу не уход к общематематической проблематике. Это уход к любой над-дисциплинарной проблематике! Хотите рассуждать не замечая это модальная логика или теория вероятностей - пожалуйста! Доктрина и внутренняя конструкция дадут вам инструмент. Только сначала нужно дать возможность нарешать те самые задачки.

ТК не белый стих. Это супер-гекзаметр :)

"что то меньшее чем теория категорий" - это уже общеизвестные внутридисциплинарные языки. Промежуток ничем не заполнен. ТК - это копредел междисциплинарных языков :))

То есть матан это уже дисциплинарный язык ;-)

Смотрите в каком смысле: матан не способен переносить знания между любыми наперед-заданными дисциплинами, например между модальной логикой и теорией вероятостей, или между алгеброй и топологией. А ТК способна. Поэтому да, дисциплинарный. Нет потенциала двигаться "за пределы".

Перенос знания из одной предметной области обычно называется "подход" (когда набор понятий и способов их употребления, наработанный в одной предметной области несут в другую предметную область -- системный подход тут ничем не отличается). То есть теория категорий это общая теория подходов, получается? Тогда понятно, почему она не завоёвывает мир быстро: та же история, что с ISO 15926. Любая "на коленке" интеграция между последовательностью пар дисциплин в рамках отдельного проекта легко побеждает "всеобщую интеграцию всех дисциплин", ровно как цепочка попарных интеграций (слегка автоматизированных какой-нибудь "корпоративной шиной") побеждает в софтверных информационных проектах. Никаких "всемирных RDL", всегда клингон какой-то кучки людей внутри интеграционного проекта. Если идти вдоль этой аналогии, то всё заранее тухло. Нужно что-то более интересное, чем простой "перенос знаний". Возможно, перенос знаний, но не "простой".

Все правильно Вы говорите. С одним маленьким отличием: ТК успешно и реально используется для построения тех самых попарных интеграций, которые по Вашим словам должны ее "порвать". А вот не рвут, наоборот используют. Связано это с простой вещью: ТК положила в свою основу то, что независимо и с трудом было переоткрыто в разных дисциплинах: роль и методика морфизмов. Так что да, обычно такие вещи получаются тухлыми. Единственно потому, что хорошие вещи такого масштаба делать очень и очень трудно.

Иными словами, ТК дает не непосредственный способ переноса знаний, а хорошую, выверенную методику построения процесса такого переноса.

Вообще-то методики сейчас описываются на языках ситуационной инженерии методов (а эти языки в свою очередь описываются на каких-то других языках -- типа OMG Essence описали на MOF). Можно ли поглядеть на описание методики построения процесса переноса знаний? И заодно поглядеть на пару-тройку результатов применения этой методики: на процессы переноса знаний? Это ведь очень важно: рефлексировать методики и описывать их!

Можно! Я приду сам и расскажу как это делается, с реальными примерами. Но саму методику только тем, кто сначала научится решать уравнения в морфизмах. :) Ну, в смысле (как частный пример) - считать пределы и копределы. Это небольшая и относительно простая часть ТК,

Кстати, часть методики, а именно "доктрина моноидальных категорий", описана в Rosetta Stone Баеца сотоварищи.

а в это время скушные инженеры делают банальные автоматические описатели картинок : http://www.nytimes.com/2014/11/18/science/researchers-announce-breakthrough-in-content-recognition-software.html?_r=0

"Как это делается" -- что? Примеры применения методики, не раскрывая деталей методики? Насколько это осмысленно? А есть ли где что-то типа учебничка, где даются те 10-15 (или 30-50?) понятий, нужных для понимания методики? Прямо как в учебниках арифметики -- сначала абстрактный пример, а затем пример из жизни (2+2=4, пример: два яблока плюс два яблока равно четыре яблока)? И упражнения на проверку, научились ли "решать уравнения в морфизмах" (на диаграммах или ещё как). Что-то типа книжки Криса Партриджа, в которой рассказывается про семантическое представление информации и 4D экстенсионализме -- так, что даётся привязка к реальной жизни (но в отрыве от конкретных стандартов, языков, задач программирования баз данных и т.д., чисто "идеологически"). Я думаю, если предварительно дать людям ознакомиться с коротким таким материалом по нужным базовым понятиям, то жизнь сильно упростится. Я знаю многих и многих людей, которые давали себе труд прочесть книжку BORO, и дальше у них с моделями данных становилось всё налажено. То же самое с ситуационной инженерией методов после появления Essence. Думаю, что тут то же самое можно сделать: дидактический прорыв по азам ТК и пример "методики" как приложения к system thinking (междисциплинарной связи).

Вот выдрать бы все эти куски текста из разных мест и собрать в одном. Розеттский камень ведь большой, а как я понял, оттуда не всё нужно. А что нужно, то разжевать бы чуть подробней, дать чуть больше примеров.