Комментарии 142
А за что так активно минусуют человека?
Ну вот например:
Можно ли интерпретировать запись о том, что станок существует с 1939 по 1990 год как утверждение не о множестве, а как утверждение об интервале времени? Да, можно. Но с такой трактовкой нельзя получить ответ на вопрос: существовал ли станок с 1956 по 1958 год?
Разумеется, ответ на этот вопрос получить можно, ведь интервал с 1956 по 1958 входит в интервал с 1939 по 1990. Из истинности предиката на множестве следует его истинность на любом подмножестве.
Но у вас, конечно же, свои определения слов "существует", "интервал", "время" и "предикат"...
Да, интервал — это разновидность множества. В общепринятых определениях, конечно же.
Из этого делается вывод, что интервал — объект.
В ООП, напоминаю, все — объект. Даже множество — объект.
Интервал множество???? То есть, в ООП он моделируется классом??
Между этими двумя вопросами нет никакой связи.
Если же речь идет о множестве, то как оно моделируется при помощи ООП?
С "помощью ООП" моделируется (в данном случае) интервал, а не множество. В этой модели могут быть определены предикаты "входит".
Когда я как ИТ специалист говорю об интервале, я говорю о математическом понятии. Совершенно не обязательно что я вообще буду вводить в программе отдельный класс или объект «интервал», это слишком мелкая абстракция; скорее всего этот интервал так и останется в виде двух переменных.
Кроме того, не забывайте о контексте. Мой комментарий выше был про логику, а не про программирование.
Пожалуйста, не надо мне приписывать того, что я не говорил.
только им пользоваться нельзя
Удивительное дело, пользоваться нельзя, а разработанные системы — есть.
не получается моделировать утверждения штатным образом
Что такое "штатный образ"?
ООП претендует на стандарт моделирования предметных областей.
Нет, не претендует. Вы выдумали себе пугало и боретесь с ним.
За необоснованные утверждения.
Например, вот вам два:
Можно ли интерпретировать запись о том, что станок существует с 1939 по 1990 год как утверждение не о множестве, а как утверждение об интервале времени? Да, можно. (1) Но с такой трактовкой нельзя получить ответ на вопрос: существовал ли станок с 1956 по 1958 год? (2) Такой способ моделирования не используется.
И вот вам третье:
Беда нашего языка в том, что невозможно разделить эти две разные трактовки одних и тех же слов.
Дальше, извините, копировать лень.
Кандрашина Е.Ю., Литвинцева Л.В., Поспелов Д.А. Представление знаний о времени и пространстве в интеллектуальных системах. Я когда-то начал с этого...
Множество является фундаментальным понятием; такие понятия вводятся не конструктивно, а аксиоматически. А потому они не могут быть выражены (конкретными) классами, только интерфейсами.
> Как множества моделируются в ООП
Полностью — никак, потому что существует бесконечное количество невычислимых множеств; поэтому модели ограничиваются лишь конкретными разновидностями множеств.
Наиболее общая разновидность — вычислимое множество — в ООП становится интерфейсом с одним методом вроде Contains, который проверяет принадлежность элемента множеству.
Однако обычно используется намного более узкий тип множеств — конечное множество, в таком случае в интерфейсе появляется метод получения количества элементов и способ перечисления этих элементов.
Интервал же — вполне конкретная конструкция, которую без труда можно выразить классом. Но интерфейс конечного множества интервал обычно не реализует, потому что он, как правило, является бесконечным множеством.
В простейшем же случае предикат второго порядка напрямую моделируется функцией второго порядка.
Это утверждение в предикатах второго порядка, которое я не могу смоделировать при помощи ООП штатными средствами.
Серьезно?
executor = hrDepartment.anyEmployee;такое класс в ООП
Начнем с первого вопроса: а зачем?
Как множества моделируются в ООП
Так, как этого требует задача. Разные задачи приводят к разным моделям.
если интервал времени — это множество, то почему оно моделируется датой начала и датой конца
А кто вам сказал, что интервал времени моделируется датой начала и конца?
ни один комментатор не объяснил, что такое класс в ООП
Вам это объясняли неоднократно в предыдущих статьях.
если интервал времени — это множество, то почему оно моделируется датой начала и датой конца?
Оно может моделироваться датой начала и датой конца. А может по-другому.
Почему может? Потому что это правило. Применительно к станкам это правило вида "станок существовал на протяжении всего указанного периода и в любой интервал времени между указанными датами".
Альтернативой этому высказыванию было бы хранение информации о всех возможных интервалах, в течение которых станок был признан существующим. Но все возможные интервалы времени на протяжении этого срока даже с шагом дискретизации в сутки – это огромный массив данных.
Ваши "все возможные интервалы" с некоторым шагом дискретизации принципиально ничем не отличаются от одного возможного интервала "1939 — 1990". Потому что и там и там считается, что "станок существовал на протяжении всего указанного периода и в любой интервал времени" между событиями дискретизации.
Вы заметили, что работа с датами в запросах, которые мы строим, отличается от работы с данными другого типа?
Работа с интервалами дат ничем не отличается от работы с интервалами расстояний.
интервалы времени, которые неделимы
Приведите пример неделимого интервала, потому что для меня интервал непрерывен, и его всегда можно разделить.
Например любой интервал можно разделить на два: от начала и до середины, от середины и до конца.
ООП, как и любая другая парадигма программирования, описывает методику моделирования абстракций. С точки зрения программирования, и интервал и множество — это в первую очередь абстракции. И любой нормальный программист смоделирует их так, как это будет удобно и полезно в рамках выбранной парадигмы.
ps
«Любой нормальный» — сильное утверждение, но это моё имхо.
Если для вас все интервалы делимы, то вы имеете дело со множествами
Это если считать, что множество это не объект. А если считать, что это объект, то проблем никаких не возникает.
Надо делить интервалы времени, которые неделимы от интервалов, которые делимы. Объекты надо отделить от мнложеств.
Кому надо?
потому что есть расстояния как объекты — они неделимы и есть расстояния, которые делимы
Нет таких видов расстояний. Все из чего-то состоит, до пределов единиц квантования. Это никак не мешает нам выделять объекты и работать с ними.
как в ООП моделируются предикаты второго порядка.
Определение
In mathematical logic, a second-order predicate is a predicate that takes a first-order predicate as an argument.
Из чего следует, что самый простой способ — это моделировать функцией, которая принимает в качестве аргумента другую функцию, которая моделирует предикат первого порядка. Также есть понятие «обобщенные типы», когда один тип является аргументом в определении второго типа.
Формально эта информация записывается так: для любого элемента множества временных интервалов с 1939 года по 1990 верно следующее: в течение этого интервала времени существовал указанный станок. Это и есть моделирование в предикатах второго порядка.
Вы хотите сказать, что «временной интервал с А по Б» — это предикат? Какой он арности и на каких типах аргументов определен?
А зачем нам договариваться об этом тезисе?
Вы очень хотите убедить всех присутствующих в важности такого разделения между объектом и множеством, но совсем не объясняете, зачем. Зачем вводить сложность там, где реальность моделируется более простыми средствами?
И почему это вдруг в ИС не моделируются интервалы?.. И чём принципиальная разница, с точки зрения программирования, утверждений "просто существовал указанный интервал" и "он существовал в любой интервал из указанного"?
Мне интересны различия, особенно, если они а) внятны и б) полезны.
Ваши термины не блещут ни тем, ни другим.
Если у нас есть кусок ткани синего цвета, то из свойств нам полезны будут размер, конкретный тон синего, тип ткани, форма… И лишь в некоем гипотетическом крайнем случае будет важно то, что все нити в этом куске синего цвета, и, о боже, любой фрагмент любой нити тоже синего цвета.
Но вопрос остаётся вез ответа — зачем делать этой крайний случай краеугольным?
Это ровно как с веществом, когда мы говорим, что в стакане вода, мы имеем ввиду не объект, а множество всех объемов, которые можно выделить из объема стакана.
Нет, это вы имеете в виду множество всех объемов. Я имею в виду именно стакан.
А промежутки всегда делимы.
Зато палку можно поделить на 2 части и получить 2 палки.
Можно поделить машину на коврик и машину.
А разница в том, что есть правило, позволяющее назвать нечто определенным термином.
Поезд зато делится на 2 поезда. Поезд теперь не объект, с ним нельзя работать как с одним целым? Дом можно разобрать и построить 2 дома. Это тоже не объект?
Машина в контексте обсуждения является квантом измерения машин.
Кроме того, предлагаю вам подумать над следующим примером. Машина без коврика это машина? А без колеса? Может человек сказать «у меня есть машина, надо только колесо купить»? А без двигателя? А если скажем взять 100 одинаковых машин, взять с каждой по одной запчасти, и собрать из них еще одну машину? Получится, что из 100 машин можно сделать 101 машину поменьше.
Интервалы времени в ИС не моделируются.
Вы хотели пример необоснованного утверждения? Вот оно, пожалуйста. Очевидно, интервалы времени моделируются — например, в ИС, отвечающей за учет имущества, "имущество было на балансе в интервал с… по ...".
Я говорю не об интервале времени
Разве?
Формально эта информация записывается так: для любого элемента множества временных интервалов с 1939 года по 1990 верно следующее: в течение этого интервала времени существовал указанный станок. Это и есть моделирование в предикатах второго порядка.
Так не пойдет. Если Вы хотите нас убедить, что это второпорядковое утверждение, покажите, где тут квантор по предикатам или второпорядковый предикат. Иначе все статья — пшик, начиная с заголовка.
Это высказывание первого порядка, т.к. «множество» и «свойство элементов множества» — равноправные элементы универса. Именно непонимание того, что такое универс в логике предикатов, Вас подводит. Хотя, конечно, не только это.
Для формулирования такого высказывания достаточно включить в теорию арифметику, функцию взятия мощности множества и предикат равенства. Либо, если для решаемой задачи это слишком сильная теория и достаточно выражать проценты с заданной точностью, то сойдет и трехместный предикат ПроцентноеСоотношениеМножеств(Множество, Множество, Процент).
Можно, кстати, примитивный вопрос? Чем плоха (или почему недопустима) трактовка предиката как функции, возвращающей ответ из множества {0, 1}?
Ну и надо понимать, что такие функции делают истинностные значения термами и, как следствие, элементами универса. Т.е. Вы получите всякие странности, например, кванторы будут бегать не только по объектам, но и по истинностным значениям. И чтобы это не приводило к проблемам, во всех формулах постоянно придется ставить ограничения на типы аргументов предикатов и функций.
А для программиста, реализующего заданную теорию в коде, это вполне нормальная трактовка, если она дает ему какие-то бонусы, по производительности, например.
Ну то есть типовая для многих языков программирования формулировка predicate(T) = function T -> bool (где T — это тип элемента в множестве) для практических задач вполне разумна?
Спасибо. Это позволяет ответить на повторяющийся тут вопрос "как в ООП представляются предикаты второго порядка" — как функции второго порядка, или, в общем случае, функции высшего порядка, что давно является решенной задачей.
Естественно, это все верно с оговоркой "если для конкретной задачи это оправданно и достаточно".
А вот «Спецификация» как по мне, вполне себе отвечает запросу автора.
Иногда время формализуют и в классической логике, для некоторых задач это возможно, но интервальная формализация, пожалуй, худшая из возможных, т.к. я не могу придумать ни одной разумной задачи, где бы такая формализация была продуктивной.
А что не так со временем в логике?
А это, в свою очередь, приводит к куче трудностей: множество, которому принадлежит Т — оно какую мощность имеет? Как эти элементы соотносятся между собой? Как описать «поведение» предикатов и функций с течением времени, если оно имеет какие-то известные закономерности?
Т.е. не то чтобы на эти вопросы нельзя ответить, просто универсального ответа нет, и формализация времени, если уж уж в качестве формализма взята классическая логика, всегда делается под конкретную задачу.
Насколько я могу понять, автор и пытается с этими трудностями разобраться. Но как-то не с того конца…
А про неразрешимость я вроде бы ничего не говорил, только про зависимость решения от задачи.
Как программист я бы вовсе не рассматривал модели Крипке как что-то связанное со временем.
Чтобы описать интервал, вам точно так же нужен момент начала интервала и момент конца интервала. Ну или момент начала интервала и его длительность. В любом случае момент начала должен присутствовать. Поэтому вам все равно придется вводить понятие мгновения, которое, по вашим соображениям, требует понятия континуума.
Потому что она опирается на понятие мгновения
Она опирается на понятие шага дискретизации. Мгновением считается промежуток в пределах этого шага. То есть, приведенное утверждение равносильно тому, что насколько бы частей мы не поделили исходный промежуток, состояние объекта в пределах любой из них будет таким же. Как видите, никакого континуума не требуется.
Вы, скорее всего, решаете какую-то определенную задачу, и потому вам, возможно, потребуется другой обьект, не Interval. Но я так и не смог понять, для решения какой задачи нужно зачему-то разбивать интервал на континуумы и хранить их.
И не хватает выводов, что с того, что Interval такой, а не другой (который вам нужен)? Чем такое моделирование плохо?
В ООП просто нет возможности моделировать множества средствами ООП.
Моделирование множеств отдается на откуп программиста.
Взаимоисключающие параграфы.
Я бы сказал так: нет штатных методов моделирования множеств.
Есть. В ООП все есть объект, следовательно, штатный метод моделирования множества в ООП — моделирование его как объекта.
Если я хочу сообщить, что 70 процентов элементов множества обладают свойством ИКС
Что значит "сообщить"? Кому? В какой момент?
Нужен штатный механизм языка моделирования
Кому нужен?
такие слова, которые нам принес ООП, как «экземпляр этого процесса»Если вы не понимаете, что означает слово экземпляр, это не значит, что это слово неправильное, и уж тем более что оно должно исчезнуть по вашему желанию.
Вы же сами пишете:
habrahabr.ru/post/343316
Поэтому одно скакание не есть то же скакание, но похожее.
Скакание это процесс?
Раз уж вы применили некрасивый прием ведения дискуссии «уход от ответа», я напомню вам сам.
Вы писали:
Инструкция — это типовой сценарий (модель процессов, типовой процесс, регламент), последовательность ваших действий — это сценарий, процесс.
Типовой сценарий — это тип. «Обычный» сценарий — это экземпляр. Что тут сложного?
Возвращаясь к вопросу. «Одно скакание» и «другое скакание» — это экземпляры. То, что означает термин «скакание» — это тип. От того, что вы их для себя называете другими словами, значение терминов в другой предметной области не поменяется.
Правильность термина может быть определена только в рамках системы терминов.
Не надо говорить экземпляр процесса «принять заказ», а надо — процесс «принять заказ»
Почему это? Почему вы считаете, что ваши термины правильные, а другие нет?
А по-английски называть тоже никому нельзя, раз лично вы говорите по-русски? При этом ведь тоже другие слова используются. Это не риторический вопрос, ответьте пожалуйста, в чем вы видите разницу.
Хорошо, допустим, некто сказал фразу 'процесс «принять заказ»'. Как понять, он имеет в виду типовой процесс, или нетиповой?
К сожалению, на сегодняшний день, словосочетание «предикат второго порядка» для меня звучит как «абра-кадабра», но для «Примера со станком» я, по крайней мере, в общих чертах могу представить реализацию. Можно попросить сформулировать задачу про множество объектов и 30% и 70% процентов в виде практического примера, «в станках»? Например:
«На текущий момент в бизнес-центре в 100 офисах 100 принтеров: 30 принтеров марки Canine, 70 принтеров марки Epsilon; переходим к формированию поофисного списка…» Оно?
Информация о рубке содержит Информация о срубленном дереве в нужном количестве; Информация о срубленном дереве содержит поле Порода дерева, которое может принимать одно из значений «Ель», «Берёза», «Не уточнено». Информацию касательно процентного соотношения можно получить через Информация о рубке, например. Зависит от того, откуда оно взялось: то ли задание нарубить было в процентах, то ли в лесу столько растёт… То же с менегерами. Информация об исполнителе содержит поле Отдел исполнителя, булево поле Назначен конкретный исполнитель, поле Конкретный исполнитель с типом данных, обозначающим сотрудника. Либо без буля, с магическим объектом сотрудника «Любой сотрудник».Например, когда мне надо смоделировать менегера, ООП называет его экземпляром этого менегера, когда мне надо смоделировать класс менегеров, у меня нет штатного механизма, когда мне надо смоделировать тип менегеров, ООП называет его менегером.
Нет и еще раз нет. Слушайте, уже сколько раз вам говорили: вы просто не понимаете, как работает ООП, зачем вы в него лезете? Вы же не программист, в конце концов, занимайтесь своим моделированием спокойно.
ООП не моделирует предметные области, но хорошо подходит для программирования.
Главное, не забывать, что в процессе программирования может возникать модель предметной области (и чаще всего возникает).
Главное — не тащить термины ООПв предметную область, чего так любят делать.
Кто любит-то? Я, например, неоднократно говорил вам, что тащить термины из любой имплементации, не важно, ООП это или БД (или теория типов, или машинное обучение, или что угодно еще) в предметную область — неправильно, и этого надо избегать.
когда мне надо смоделировать класс менегеров, у меня нет штатного механизма
Откуда взялось понятие "класс менегеров" в предметной области? Кажется, вы сами только что зачем-то вытащили технический термин в предметную область.
И то же самое по поводу "типа менегера" — в предметной области его тоже не существует. Либо существует, но означает что-то совсем иное, и ООП точно не называет его менегером.
Объе́кт в программировании — некоторая сущность в компьютерном пространстве, обладающая определённым состоянием и поведением, имеющая заданные значения свойств (атрибутов) и операций над ними (методов).(Объект (программирование))
Класс — это элемент ПО, описывающий абстрактный тип данных и его частичную или полную реализацию.
Практически класс может пониматься как некий шаблон, по которому создаются объекты — экземпляры данного класса. Все экземпляры одного класса созданы по одному шаблону, поэтому имеют один и тот же набор полей и методов.
В объектно-ориентированной программе с применением классов каждый объект является «экземпляром» некоторого конкретного класса, и других объектов не предусмотрено. То есть «экземпляр класса» в данном случае означает не «пример некоторого класса» или «отдельно взятый класс», а «объект, типом которого является какой-то класс».(Класс (программирование))
Т. е.
Manager manager1 = new Manager(); создаёт экземпляр ООП-класса Manager, т. е. создаёт некую численно описывающую менегера структуру в соответствии с шаблоном Manager. Поскольку ООП-классы не являются необходимым компонентом ООП, можно достичь аналогичного эффекта через Object manager1 = createManager();. Т. е. «экземпляр процесса» — не более чем фигура речи, сленг. Вас, как я понимаю, больше интересовал не ООП-класс (шаблон создания информационной структуры), а класс как множество объектов, имеющих некоторый признак(и), или как набор самих признаков, по которым объект может быть отнесён к этому классу. Так ли это?Насчёт множеств, насколько я знаю, примитивный тип данных
set — это фактически сахар для битовой карты. Т. е. речь идёт о фиксированном наборе идентификаторов, для каждого из которых хранится информация, присутсствует ли он в этом «множестве» или нет. Если говорить о множестве как о динамически определяемой совокупности объектов… ООП позволяет создавать объекты, трактовкой же их занимается программист, поэтому ничто не мешает создать объект, моделирующий множество: содержащий список членов множества, операции добавления, удаления членов и проверки вхождения значения в множество, пересечения и т. д.В конце концов, можно создать язык программирования (или диалект), соответствующий вашим терминологическим потребностям. Фреймворк, наконец. А, может, он уже есть.
термины, которые не переводятся на русский язык, например, экземпляр этого процесса
программисты реально думают, что такой термин допустим в русском языке
Ну сколько можно говорить. Такое словосочетание может иметь смысл в некотором контексте. Это не является общепринятым термином, это отсылка к нему в редуцированном виде. Правильный термин другой. Почему вы продолжаете высказывать заведомо неверные утверждения?
Я не знаю, насколько надо не любить ни логику, ни язык
Комменты и выше и в других статьях написаны русским языком. Насколько надо не любить ни логику, ни язык, чтобы не понимать одних и тех же доводов, повторенных много раз?
Вы высказываете необоснованные утверждения и уходите от ответа, когда спрашивают о причинах или приводят противоречащие этому примеры.
Вы задаете вопросы, и получив ответы, продолжаете задавать их же в дальнейшем, хотя не приводите контр-аргументов, почему ответ вам не подходит.
Вы даже не смогли сформулировать ответ на вопрос, в чем вы видите различия между другими названиями на одном языке и названиями на другом языке.
Что там про логику и владение языком?
Потому что из-за скошенных терминов в предметные области стали проникать термины
Нет, термины в предметные области стали проникать из-за недостаточной аккуратности в процессе разработки.
Вы думаете, термины "таблица БД" и "запись БД" в бизнес-требованиях чем-то лучше "класса"?
Посмотрите выше и вы поймете, что программисты реально думают, что такой термин допустим в русском языке и имеет какой-то смысл!
В русском языке допустим любой "термин", потому что в языке терминов нет, они есть только в предметной области.
Вы разницу видите?
Разницу между чем и чем? Из вашего комментария даже не понятно, кто как говорит, и как по-вашему надо.
вместо того, чтобы сказать тип процессов вы говорите процесс
Я? Нет, я так не говорю.
чем экземпляр процесса отличается от процесса, мне говорят, что ничем
Вам говорят, что то, что вы называете "просто процесс", в другой системе терминов называется "экземпляр типа 'Процесс'".
Я спрашиваю: по логике это значит, что можно заменить термин экземпляр этого процесса на процесс.
Нет, вы не говорили о замене одного правильного термина на другой. Вы говорили, что термин "экземпляр" неправильный. Спорят с вами по поводу правильности, а не по поводу замены.
Кстати, почему вы продолжаете употреблять выражение "экземпляр этого процесса", если вам сказали, что в отрыве от контекста оно не употребляется? Правильная форма — "экземпляр типа 'Процесс'" или "экземпляр этого типа", в крайнем случае "экземпляр процесса '<более конкретное название типа процессов>'". Если вы собираетесь снова обсуждать это в дальнейших статьях, используйте одну из этих форм, чтобы быть понятым другими.
Но мне отвечают, что в ООП это сделать нельзя.
Не могли бы вы привести ссылку, где именно вам такое сказали?
Вам говорили о том, что термин "экземпляр" корректен, и что отказ от него будет вызывать неоднозначность в выражениях вида 'процесс «принять заказ»'. На вопрос, как устранить неоднозначность в вашей системе терминов, вы тоже ответить не смогли.
но тип называет именем объекта, а объект — именем объекта с приставкой экземпляр этого
Вы пишете:
"Поверхность – это проекция 4-Д объема на пространство в виде поверхности, ограничивающей объем."
Здесь вы явно говорите не о конкретной поверхности, следовательно, о типовой.
Почему вы типовое понятие называете именем объекта (а именно словом "поверхность"), если считаете, что это неправильно?
И нет, тип называют именем с приставкой "тип", а объект именем с приставкой "экземпляр". Если это не ясно из контекста, либо если ясно, но нужно сослаться на другой смысл.
P.S. Если у вас есть возражения, не могли бы вы высказывать их прямо, а не косвенно через комментарий другого человека. Это к вопросу о вашей логике.
«Экземпляр класса Process (типа данных, описанного как ООП-класс)» — корректное выражение, «экземпляр Process'а» — разговорная форма; «экземпляр объекта типа Process», «экземпляр процесса (предметно-областного)» — некорректные выражения. Соответственно, «экземпляр Process'а» и «экземпляр процесса (предм.)» не взаимозаменяемы.
Что касается типа и объекта типа, если мы говорим о «типе данных» в компьютерной программе, то они различаются согласно принятой форме записи.
Это утверждение относительно множества менегеров, а не относительно менегера
А вот кстати нет. Это утверждение относительно неизвестного на данный момент объекта, удовлетворяющего некоему критерию (в данном случае — "менеджер из отдела").
Ну и как бы все равно не понятно, какую задачу вы решаете.
Как мы моделируем предметную область в предикатах второго порядка и не замечаем этого