Любая модель обладает ограниченной точностью. Чем более точную модель надо построить, тем больше информации для этого придется хранить. Если есть возможность свернуть массив данных по какому-то из критериев, то такая свертка позволяет резко сократить объем хранимой информации. Однако, такая свертка не моделируется штатными способами моделирования, потому что требует моделирования высказываний одновременно и относительно множеств объектов, а не относительно объектов этих множеств. Фактически, нам нужен инструмент для моделирования как предикатов первого порядка, так и предикатов второго порядка.
Поясню на самом распространенном примере. Когда мы пишем, что станок был выпущен в 1939 году, а утилизирован в 1990, мы имеем ввиду, что станок существовал на протяжении всего указанного периода и в любой интервал времени между указанными датами. Альтернативой этому высказыванию было бы хранение информации о всех возможных интервалах, в течение которых станок был признан существующим. Но все возможные интервалы времени на протяжении этого срока даже с шагом дискретизации в сутки – это огромный массив данных.
Пользоваться этим массивом данных так же неудобно, как и его хранить. Строить запросы к этому массиву данных – тоже неудобно. Например, у нас есть запись о том, что станок существовал с12 июня по 17 июня и находился в этот период в машинном отделении ГЭС. Но на основе этой записи мы ничего не можем сказать о существовании и нахождении станка в период с 13 июня по 15 июня, потому что при таком подходе к моделированию для ответа на это вопрос нам нужна отдельная соответствующая запись.
Чтобы не хранить каждый интервал отдельно, сократить объем хранимой информации и время на обработку запросов мы прибегаем к моделированию множества интервалов. Мы говорим, что в любой интервал времени между 1939 годом и 1990 годом станок существовал. Правда, при этом мы потеряли информацию о его местоположении, но сократили объем хранимой информации и увеличили скорость доступа к этой информации в миллионы раз. Формально эта информация записывается так: для любого элемента множества временных интервалов с 1939 года по 1990 верно следующее: в течение этого интервала времени существовал указанный станок. Это и есть моделирование в предикатах второго порядка. Мы записали свое знание в виде знания о множестве объектов: множестве всех возможных интервалов времени с 1939 года по 1990 год.
Можно ли интерпретировать запись о том, что станок существует с 1939 по 1990 год как утверждение не о множестве, а как утверждение об интервале времени? Да, можно. Но с такой трактовкой нельзя получить ответ на вопрос: существовал ли станок с 1956 по 1958 год? Такой способ моделирования не используется.
Мы видим, что одни и те же слова имеют совершенно разный смысл в зависимости от их трактовки. Если мы напишем, что станок существовал с 1939 года по 1990, то эти слова можно трактовать двумя разными способами:
- как утверждение относительно всех интервалов, которые могут быть получены из интервала с 1939 по 1990 года.
- как утверждение относительно интервала с 1939 по 1990.
Беда нашего языка в том, что невозможно разделить эти две разные трактовки одних и тех же слов. Это заставляет нас думать о том, что, указывая время начала и время завершения какой-то операции, мы моделируем интервал, а не множество всех его частей. Это приводит к неудобствам, которые мы испытываем при проектировании систем. Вы заметили, что работа с датами в запросах, которые мы строим, отличается от работы с данными другого типа? Вы задумывались: почему? Ответ в том, что, указывая интервал времени, мы моделируем утверждение относительно множества интервалов, которые можно выделить из этого интервала, а не относительно указанного интервала. Поскольку в рамках ООП, или иных аналогичных стандартов моделирования нет возможности моделировать предикаты второго порядка, становится невозможным моделирование классов временных интервалов штатным способом.
Как только мы прибегаем к сжатию информации, мы имеем дело с высказываниями относительно множеств, которое требует от нас высказываний в предикатах второго порядка, моделирование которых штатными средствами нам пока не под силу.
При моделировании объектов, когда мы указываем пространственный объем, занятый объектом, мы так же, как в случае с временными интервалами, можем одними словами выразить разные мысли. Например, можно сказать, что внутри указанного нами объема находится объект. Но есть два разных способа трактовать это высказывание. Например, есть два разных способа трактовать высказывание стакан воды.
- то ли речь идет об объекте.
- то ли речь идет о веществе.
Разница та же, что и с моделированием интервала времени и множеством интервалов. В первом случае мы моделируем объем пространства, во втором – множество всех объемов, которые можно выделить из указанного объема. Слова одинаковые, а смысл их – разный. В первом случае высказывание строится в предикатах первого порядка, во втором – второго. И так же, как мы испытываем трудности с моделированием временных интервалов, мы испытываем трудности с моделированием веществ штатными методами.
Та же проблема возникает, когда мы моделируем состояния объекта. Если сказать: с такого-то по такое-то время лампочка горела, что мы хотим эти сказать? Как правило, мы имеем ввиду, что в любой период из указанного интервала лампочка находится в состоянии свечения. То есть, то, что мы привыкли называть состоянием объекта, — это множество временных интервалов, в течении которых объект находится в похожем состоянии, а не один единственный временной интервал.
Если мы определим состояние объекта, как промежуток времени, в течении которого объект сохраняет какое-то свойство, то надо уточнить, что имеется ввиду не промежуток времени, а множество всех интервалов, которые можно получить из указанного промежутка.
Равносильной альтернативой этому утверждению было бы следующее: в любой момент из указанного диапазона объект имел одно и то же состояние. Почему я не люблю вторую трактовку данного тезиса? Потому что она опирается на понятие мгновения, которое неизбежно приводит нас к понятию континуума. Моя трактовка опирается на здравый смысл и не требует понятия континуума.
Вернемся к понятию регистрация. Я писал ранее, что под регистрацией состояния объекта может пониматься:
- разовая регистрация состояния объекта (потока, среды)
- множество регистраций похожих состояний.
При этом наше сознание не осознает разовую регистрацию. Когда ему сообщают, что в 12-00 температура воздуха была 25 градусов, сознание может сохранить эту информацию, но представить себе не может. Пользуется опытом, который говорит, что температура воздуха не могла измениться быстро, сознание предлагает свою версию, в которой представлена целая история с какого-то момента до регистрации до какого-то момента после, например, с 11-30 до 12-30. На протяжении всего этого интервала времени сознание предлагает считать температуру воздуха неизменной и равной 25 градусам. Более того, не просто на протяжении всего этого интервала, но и на протяжении любого диапазона из указанного интервала! То же происходит, когда мы видим старое здание. Мы не просто регистрируем факт того, что оно существует в момент регистрации, мы представляем его существование в течении длительного времени до этого и некоторое время после. И опять – не просто в течении этого временного интервала, а в течении любого из временных диапазонов внутри представленного нами интервала времени!
Когда же под регистрацией состояния объекта понимается множество регистраций, наше сознание продлевает гипотезу за пределы границ, которые были построены на основе одной регистрации. Например, если сообщить, что в 12-00, в 13-00 и в 14-00 температура воздуха была одинаковой и равной 25 градусам, то границы временного интервала, в течении которого мы считаем температуру неизменной, расширяются с 12-30 до 14-30.
Мы заняты получением новых данных для построения прогнозов с нужной для нас точностью, построением гипотез, и сверкой реальности с этими гипотезами.
Для этого, с одной стороны мы вынуждены добывать новые фактические данные, а с другой стремимся экономить ресурсы, необходимые для хранения этих гипотез. При этом, если фактические данные мы стараемся хранить без искажений, то гипотезы стараемся максимально сжать.
Приведу пример. Допустим, что мы знаем о том, что Иванов вышел из пункта А в 11-00 и пришел в пункт Б в 12-00, передвигаясь пешком. Чтобы представить себе это передвижение, можно представить последовательность мгновений, которые с достаточной степенью точности передадут это передвижение. Поскольку мгновений бесконечное множество, для такого способа хранения информации требуется бесконечно большой объем памяти. Однако, как мы видим, весь объем хранимой информации умещается в несколько слов и ссылку на тип передвижения. Этого достаточно, чтобы представить себе любой отрезок пути Иванова. Для этого мы выбираем любой интервал времени между 11-00 и 12-00 и заполняем его многократно растиражированным типовым движением, которое хранится у нас в памяти. Конечно, это — лишь гипотеза, но она достаточно близка к тому, чтобы предсказать нужные нам последствия. Например, после того, как мы встретим Иванова, мы можем спросить его: не устал ли он столько шагать? Все методы сжатия информации основаны на обобщениях подобного рода.
Таким образом, добавим к двум трактовкам термина регистрация новую трактовку. Под регистрацией состояния объекта в определенный интервал времени может пониматься:
- разовая регистрация состояния объекта (потока, среды), совершенная за этот интервал времени.
- множество регистраций похожих состояний, совершенных внутри этого интервала времени.
- множество всех диапазонов, лежащих внутри интервала времени, в течении которых состояние объекта считалось одинаковым.
Если первые две трактовки могут быть получены как результат проведенных исследований, то третья трактовка получена как результат гипотезы, которую мы построили на основе регистрации, или серии регистраций. Кстати, это значит, что континуум состояний – это тоже результат гипотезы, но не результат наблюдений.
Так же, как регистрацию состояния, состояние объекта в течении определенного интервала времени тоже можно трактовать тремя разными способами:
- как результат разовой регистрации, совершенной за этот интервал времени.
- как результат множества регистраций похожих состояний, совершенных внутри этого интервала времени.
- как результат построенной гипотезы о том, что состояние объекта во всех диапазонах, лежащих внутри этого интервала времени, одинаковое.
При моделировании первого тезиса мы ссылаемся из интервала времени на тип состояний. При моделировании второго тезиса мы ссылаемся из интервалов времени на тип состояний. При моделировании третьего тезиса мы ссылаемся из интервала времени на тип состояний, но смысл этой ссылки иной, нежели в первом случае.
Комментарии (141)
ondister
26.03.2018 19:48Кандрашина Е.Ю., Литвинцева Л.В., Поспелов Д.А. Представление знаний о времени и пространстве в интеллектуальных системах. Я когда-то начал с этого...
maxstroy Автор
26.03.2018 20:35-2К сожалению, ни один комментатор не объяснил, что такое класс в ООП (в матлогике — это множество). Как множества моделируются в ООП и, если интервал времени — это множество, то почему оно моделируется датой начала и датой конца?
mayorovp
26.03.2018 20:53+1Класс в ООП и множество в
матлогикетеории множеств — это совершенно разные вещи.
Множество является фундаментальным понятием; такие понятия вводятся не конструктивно, а аксиоматически. А потому они не могут быть выражены (конкретными) классами, только интерфейсами.
> Как множества моделируются в ООП
Полностью — никак, потому что существует бесконечное количество невычислимых множеств; поэтому модели ограничиваются лишь конкретными разновидностями множеств.
Наиболее общая разновидность — вычислимое множество — в ООП становится интерфейсом с одним методом вроде Contains, который проверяет принадлежность элемента множеству.
Однако обычно используется намного более узкий тип множеств — конечное множество, в таком случае в интерфейсе появляется метод получения количества элементов и способ перечисления этих элементов.
Интервал же — вполне конкретная конструкция, которую без труда можно выразить классом. Но интерфейс конечного множества интервал обычно не реализует, потому что он, как правило, является бесконечным множеством.maxstroy Автор
27.03.2018 07:59Спасибо за ответ! Но это не совсем то, что я хотел спросить. Меня интересовал вопрос моделирования предикатов второго порядка в ООП,
mayorovp
27.03.2018 08:42Все зависит от задачи. Проблема тут в том, что в математике с предикатом второго порядка можно сделать кучу разных вещей, которые будут невычислимы в общем случае — а потому модель будет зависеть от того что с этими предикатами второго порядка мы будет делать.
В простейшем же случае предикат второго порядка напрямую моделируется функцией второго порядка.maxstroy Автор
27.03.2018 09:56Главное — я утверждаю, что в ООП нет штатного механизма моделирования таких тезисов. Более ничего.
mayorovp
27.03.2018 10:00Осталось понять почему это плохо. Вот ни разу я еще не сталкивался с необходимостью программного моделирования предиката второго порядка…
maxstroy Автор
27.03.2018 12:26Я сталкиваюсь с этой необходимостью постоянно. Например, мне надо сказать, что исполнителем данной роли будет кто-то из отдела кадров, не называя, кто именно. Это утверждение в предикатах второго порядка, которое я не могу смоделировать при помощи ООП штатными средствами.
lair
27.03.2018 12:31Это утверждение в предикатах второго порядка, которое я не могу смоделировать при помощи ООП штатными средствами.
Серьезно?
executor = hrDepartment.anyEmployee;
mayorovp
27.03.2018 12:39+1Если утверждение сделано в предикатах второго порядка — это совершенно не означает что его нужно моделировать как произвольный предикат второго порядка!
maxstroy Автор
27.03.2018 12:42Покажите мне раздел документации, в котором сказано, как при помощи ООП моделируются предикаты второго порядка.
evkochurov
27.03.2018 12:46+1Не надо лезть в ООП со вторым порядком, с первым надо сначала разобраться…
evkochurov
27.03.2018 12:45Нет, это обычное первопорядковое утверждение с квантором существования, автор просто плохо разбирается в формальной логике.
mayorovp
27.03.2018 12:48Любое утверждение первого порядка может быть сведено к утверждению второго порядка. А любая разрешимая задача может быть сведена к неразрешимой, чем автор и занимается :-)
lair
26.03.2018 21:25такое класс в ООП
Начнем с первого вопроса: а зачем?
Как множества моделируются в ООП
Так, как этого требует задача. Разные задачи приводят к разным моделям.
если интервал времени — это множество, то почему оно моделируется датой начала и датой конца
А кто вам сказал, что интервал времени моделируется датой начала и конца?
michael_vostrikov
27.03.2018 05:06ни один комментатор не объяснил, что такое класс в ООП
Вам это объясняли неоднократно в предыдущих статьях.
если интервал времени — это множество, то почему оно моделируется датой начала и датой конца?
Оно может моделироваться датой начала и датой конца. А может по-другому.
Почему может? Потому что это правило. Применительно к станкам это правило вида "станок существовал на протяжении всего указанного периода и в любой интервал времени между указанными датами".
michael_vostrikov
27.03.2018 05:01Альтернативой этому высказыванию было бы хранение информации о всех возможных интервалах, в течение которых станок был признан существующим. Но все возможные интервалы времени на протяжении этого срока даже с шагом дискретизации в сутки – это огромный массив данных.
Ваши "все возможные интервалы" с некоторым шагом дискретизации принципиально ничем не отличаются от одного возможного интервала "1939 — 1990". Потому что и там и там считается, что "станок существовал на протяжении всего указанного периода и в любой интервал времени" между событиями дискретизации.
Вы заметили, что работа с датами в запросах, которые мы строим, отличается от работы с данными другого типа?
Работа с интервалами дат ничем не отличается от работы с интервалами расстояний.
maxstroy Автор
27.03.2018 06:48Верно, потому что есть расстояния как объекты — они неделимы и есть расстояния, которые делимы, потому что они по сути, как и вещества — не есть объекты, а есть множества. Об этом и статья. Надо делить интервалы времени, которые неделимы от интервалов, которые делимы. Объекты надо отделить от мнложеств. Но, я так понял, это как раз вы и не поняли. Кроме того, я так и не услышал, как в ООП моделируются предикаты второго порядка.
Deosis
27.03.2018 07:28интервалы времени, которые неделимы
Приведите пример неделимого интервала, потому что для меня интервал непрерывен, и его всегда можно разделить.
Например любой интервал можно разделить на два: от начала и до середины, от середины и до конца.maxstroy Автор
27.03.2018 07:53Если для вас все интервалы делимы, то вы имеете дело со множествами. Не более. Но, если мы увидим неделимые интервалы, то это будут объекты. И вот вопрос: как в ООП построена работа со множествами?
Mikluho
27.03.2018 09:11+1Ответ на вопрос «как в ООП построена работа со множествами?» — никак. ООП не про это.
ООП, как и любая другая парадигма программирования, описывает методику моделирования абстракций. С точки зрения программирования, и интервал и множество — это в первую очередь абстракции. И любой нормальный программист смоделирует их так, как это будет удобно и полезно в рамках выбранной парадигмы.
ps
«Любой нормальный» — сильное утверждение, но это моё имхо.maxstroy Автор
27.03.2018 09:32-1Если верно то, что вы говорите, то ООП не может претендовать на моделирование предметных областей, о чем я постоянно говорю.
mayorovp
27.03.2018 09:48Вы путаете разные виды моделирования. Модель может быть математической, а может быть программной. ООП не претендует на построение первых, но успешно делает вторые.
Mikluho
27.03.2018 09:49Тогда у меня для вас печальная весть: язык наш тоже ничего такого не определяет. Он тоже лишь «описывает методику моделирования абстракций» и даёт некоторое количество примитивов. Сам по себе он «не может претендовать на моделирование предметных областей». Но вы зачем то им пользуетесь…
michael_vostrikov
27.03.2018 10:39+2Если для вас все интервалы делимы, то вы имеете дело со множествами
Это если считать, что множество это не объект. А если считать, что это объект, то проблем никаких не возникает.
lair
27.03.2018 10:11Надо делить интервалы времени, которые неделимы от интервалов, которые делимы. Объекты надо отделить от мнложеств.
Кому надо?
michael_vostrikov
27.03.2018 10:38+1потому что есть расстояния как объекты — они неделимы и есть расстояния, которые делимы
Нет таких видов расстояний. Все из чего-то состоит, до пределов единиц квантования. Это никак не мешает нам выделять объекты и работать с ними.
как в ООП моделируются предикаты второго порядка.
Определение
In mathematical logic, a second-order predicate is a predicate that takes a first-order predicate as an argument.
Из чего следует, что самый простой способ — это моделировать функцией, которая принимает в качестве аргумента другую функцию, которая моделирует предикат первого порядка. Также есть понятие «обобщенные типы», когда один тип является аргументом в определении второго типа.
evkochurov
27.03.2018 06:30Формально эта информация записывается так: для любого элемента множества временных интервалов с 1939 года по 1990 верно следующее: в течение этого интервала времени существовал указанный станок. Это и есть моделирование в предикатах второго порядка.
Вы хотите сказать, что «временной интервал с А по Б» — это предикат? Какой он арности и на каких типах аргументов определен?maxstroy Автор
27.03.2018 06:35Спасибо за коммент! Я говорю не об интервале времени. Интервалы времени в ИС не моделируются. В этом вся проблема. Моделируются классы интервалов. Когда мы пишем, что объект А существовал с такого-то по такое, мы имеем ввиду, что он существовал в любой интервал из указанного, а не просто существовал указанный интервал. Это ровно как с веществом, когда мы говорим, что в стакане вода, мы имеем ввиду не объект, а множество всех объемов, которые можно выделить из объема стакана. В любом из выделенных объемов есть вода. Мы так думаем, но не понимаем этого. Об этом статья. Разница между временным интервалом1 и временным интервалом2, между объектом и веществом именно в том, что в одном случае мы говорим об объекте, а во втором — о множествах объектов. Давай сначала договоримся об этом тезисе.
Mikluho
27.03.2018 08:50+1А зачем нам договариваться об этом тезисе?
Вы очень хотите убедить всех присутствующих в важности такого разделения между объектом и множеством, но совсем не объясняете, зачем. Зачем вводить сложность там, где реальность моделируется более простыми средствами?
И почему это вдруг в ИС не моделируются интервалы?.. И чём принципиальная разница, с точки зрения программирования, утверждений "просто существовал указанный интервал" и "он существовал в любой интервал из указанного"?maxstroy Автор
27.03.2018 09:27-1Если вы не различаете красный и синий, это не значит, что все не различают. Если вам различия не интересны, то для вас нет вопроса и нет ответа.
Mikluho
27.03.2018 09:45Вот, вы опять вместо ответа на вопрос, начинаете вилять словами.
Мне интересны различия, особенно, если они а) внятны и б) полезны.
Ваши термины не блещут ни тем, ни другим.
Если у нас есть кусок ткани синего цвета, то из свойств нам полезны будут размер, конкретный тон синего, тип ткани, форма… И лишь в некоем гипотетическом крайнем случае будет важно то, что все нити в этом куске синего цвета, и, о боже, любой фрагмент любой нити тоже синего цвета.
Но вопрос остаётся вез ответа — зачем делать этой крайний случай краеугольным?
mayorovp
27.03.2018 09:29Это ровно как с веществом, когда мы говорим, что в стакане вода, мы имеем ввиду не объект, а множество всех объемов, которые можно выделить из объема стакана.
Нет, это вы имеете в виду множество всех объемов. Я имею в виду именно стакан.
maxstroy Автор
27.03.2018 09:42Если вы имеете ввиду стакан воды, то это объект неделимый, как и промежуток времени может быть неделимым, как и расстояние — тоже. В языке нет маркера, который бы говорил нам. о чем идет речь: об объекте, или о множестве. Из-за этого проблемы с пониманием и моделированием.
mayorovp
27.03.2018 09:50Физическая неделимость объекта не означает что его нельзя поделить мысленно.
А промежутки всегда делимы.maxstroy Автор
27.03.2018 09:58Нельзя поделить машину на части и получить много разных машин, а время — можно. В чем разница?
michael_vostrikov
27.03.2018 10:47Зато палку можно поделить на 2 части и получить 2 палки.
Можно поделить машину на коврик и машину.
А разница в том, что есть правило, позволяющее назвать нечто определенным термином.maxstroy Автор
27.03.2018 10:57-1Машина не делится на две машины, а интервал времени делится на два интервала. Собственно, если это не понятно, то не стоит тратить время.
michael_vostrikov
27.03.2018 12:29Ну не делится, и что? Почему то, что делится на составные части не может быть объектом? Даже термин такой есть — составной объект.
Поезд зато делится на 2 поезда. Поезд теперь не объект, с ним нельзя работать как с одним целым? Дом можно разобрать и построить 2 дома. Это тоже не объект?
Машина в контексте обсуждения является квантом измерения машин.
Кроме того, предлагаю вам подумать над следующим примером. Машина без коврика это машина? А без колеса? Может человек сказать «у меня есть машина, надо только колесо купить»? А без двигателя? А если скажем взять 100 одинаковых машин, взять с каждой по одной запчасти, и собрать из них еще одну машину? Получится, что из 100 машин можно сделать 101 машину поменьше.
lair
27.03.2018 10:13+1Интервалы времени в ИС не моделируются.
Вы хотели пример необоснованного утверждения? Вот оно, пожалуйста. Очевидно, интервалы времени моделируются — например, в ИС, отвечающей за учет имущества, "имущество было на балансе в интервал с… по ...".
evkochurov
27.03.2018 10:50+2Я говорю не об интервале времени
Разве?
Формально эта информация записывается так: для любого элемента множества временных интервалов с 1939 года по 1990 верно следующее: в течение этого интервала времени существовал указанный станок. Это и есть моделирование в предикатах второго порядка.
Так не пойдет. Если Вы хотите нас убедить, что это второпорядковое утверждение, покажите, где тут квантор по предикатам или второпорядковый предикат. Иначе все статья — пшик, начиная с заголовка.maxstroy Автор
27.03.2018 12:30Если мы понимаем под временным интервалом неделимый отрезок времени, что еще никто и никогда не понимал, то тогда для этих отрезков мы можем построить высказывание: Для любого отрезка верно: Объект существует. при этом арность — унарная, тип переменной — логический, значения: да, или нет.
evkochurov
27.03.2018 12:42Это бессмысленное утверждение, т.к. кванторная переменная не используется в подкванторном выражении. Это демонстрирует, к сожалению, непонимание даже логики первого порядка, что уж говорить о втором…
maxstroy Автор
27.03.2018 12:58Спасибо большое! Я специально разбирался относительно высказываний и у меня вопрос: если мне надо сказать: такой-то процент элементов данного множества обладает такими-то свойствами — это высказывание в предикатах какого порядка? В частном случае я могу сказать — все сто процентов объектов обладают данным свойством.
evkochurov
27.03.2018 13:42Поскольку на Хабре не принято уходить от ответа, сделаю оговорку: Вам трудно будет его правильно понять, не разбираясь в формальной логике.
Это высказывание первого порядка, т.к. «множество» и «свойство элементов множества» — равноправные элементы универса. Именно непонимание того, что такое универс в логике предикатов, Вас подводит. Хотя, конечно, не только это.
Для формулирования такого высказывания достаточно включить в теорию арифметику, функцию взятия мощности множества и предикат равенства. Либо, если для решаемой задачи это слишком сильная теория и достаточно выражать проценты с заданной точностью, то сойдет и трехместный предикат ПроцентноеСоотношениеМножеств(Множество, Множество, Процент).lair
27.03.2018 13:49Можно, кстати, примитивный вопрос? Чем плоха (или почему недопустима) трактовка предиката как функции, возвращающей ответ из множества
{0, 1}?evkochurov
27.03.2018 14:15Тем, что этот взгляд закрывает путь к пониманию неклассических логик, где предикаты в принципе не имеют значений, ни истинностных, ни из заданного множества. А для программиста, реализующего заданную теорию в коде, это вполне нормальная трактовка, если она дает ему какие-то бонусы, по производительности, например.
Ну и надо понимать, что такие функции делают истинностные значения термами и, как следствие, элементами универса. Т.е. Вы получите всякие странности, например, кванторы будут бегать не только по объектам, но и по истинностным значениям. И чтобы это не приводило к проблемам, во всех формулах постоянно придется ставить ограничения на типы аргументов предикатов и функций.lair
27.03.2018 14:18А для программиста, реализующего заданную теорию в коде, это вполне нормальная трактовка, если она дает ему какие-то бонусы, по производительности, например.
Ну то есть типовая для многих языков программирования формулировка
predicate(T) = function T -> bool(где T — это тип элемента в множестве) для практических задач вполне разумна?evkochurov
27.03.2018 14:38Конечно.
lair
27.03.2018 14:43Спасибо. Это позволяет ответить на повторяющийся тут вопрос "как в ООП представляются предикаты второго порядка" — как функции второго порядка, или, в общем случае, функции высшего порядка, что давно является решенной задачей.
Естественно, это все верно с оговоркой "если для конкретной задачи это оправданно и достаточно".
retran
27.03.2018 16:09Справедливости ради, функции высшего порядка — это не классическое ООП.
А вот «Спецификация» как по мне, вполне себе отвечает запросу автора.lair
27.03.2018 17:13Блин, двух слов не хватило: "так же, как функции высшего порядка". То есть пуристы берут компонуемые объекты (по тому или иному паттерну), реалисты берут ОО-язык, в котором есть ФВП, и веселятся.
retran
27.03.2018 17:27Не, ну так можно вспомнить Пролог, где предикаты второго порядка есть в чистом виде как first-class citizen, или Хаскелль с его монадами.
Исходный тезис автора — в ООП не моделируются предикаты второго порядка. Это, очевидно, неправда.
maxstroy Автор
27.03.2018 13:55Спасибо еще раз! Я бы очень хотел видеть, как моделируются подобные вещи в ООП. К сожалению, я не нашел ни раздела в документации ни в книгах по ООП раздела, посвященного моделированию утверждений, которые я хочу смоделировать. Это: для любого объекта данного множества верно следующее: И на основе этого появляется возможность работать с отрезками времени как с элементами множества. А без этого утверждения не должно быть такой возможности. Тогда я смогу развести по сторонам утверждения относительно интервалов времени и утверждения относительно множеств интервалов.
lair
27.03.2018 14:03+1Что вообще вы понимаете под "моделирование в ООП утверждений"? ООП — (преимущественно) императивная парадигма, она оперирует инструкциями, а не утверждениями. Задача же "если для любого объекта в X верно Y, то" решается тривиальным
if (x.All(Y)) then.
evkochurov
27.03.2018 13:55Но все это пустое, т.к. понятие о времени (вспоминаем, с чего началась статья) очень плохо выражается в классической логике предикатов и высшие порядки тут не спасают. Это осознано давным давно и для задач, где требуется формализация понятия о времени, используют совсем другие формализмы. Смотрите, например, модели Крипке и конструктивные логики. Но, опять же, понять их можно, только хорошо понимая классическую логику.
Иногда время формализуют и в классической логике, для некоторых задач это возможно, но интервальная формализация, пожалуй, худшая из возможных, т.к. я не могу придумать ни одной разумной задачи, где бы такая формализация была продуктивной.mayorovp
27.03.2018 14:09А что не так со временем в логике?
evkochurov
27.03.2018 14:37+1Тем, что классическая логика хорошо подходит только для описания положения дел в статике. Например, «эта машина — красная» (Цвет(Красный, Машина), тут я намеренно упрощаю, автор берет примеры, где аргументами являются не конкретные объекты, а множества) хорошо формулируется, если подразумевается конкретный момент времени. Если хочется в пределах одной теории говорить о разных моментах времени, то внезапно оказывается, что утверждение, истинное вчера, становится ложным сегодня. И приходится придумывать костыли, например, во все предикаты добавить дополнительный аргумент Т (Цвет(Красный, Машина, 27.03.2018) или, как у автора — не момент времени, а интервал).
А это, в свою очередь, приводит к куче трудностей: множество, которому принадлежит Т — оно какую мощность имеет? Как эти элементы соотносятся между собой? Как описать «поведение» предикатов и функций с течением времени, если оно имеет какие-то известные закономерности?
Т.е. не то чтобы на эти вопросы нельзя ответить, просто универсального ответа нет, и формализация времени, если уж уж в качестве формализма взята классическая логика, всегда делается под конкретную задачу.
Насколько я могу понять, автор и пытается с этими трудностями разобраться. Но как-то не с того конца…mayorovp
27.03.2018 14:55Время — это лишь еще одна координата. Усложнение предикатов — это, конечно, плохо — но но задача-то от добавления времени неразрешимой не становится!
evkochurov
27.03.2018 15:14Время, как дополнительная координата — это только один из вариантов. Есть задачи, где время надо понимать сложнее. Например, если нам требуется выразить, что с течением времени наши знания растут (т.е. мы допускаем незнание об истинности некоторых утверждений, но однажды обретенное знание — не меняется и не теряется) и мы хотим понять, какими эти знания могут стать (или могли быть), а какими — нет. Вот тут и появляются модели Крипке.
А про неразрешимость я вроде бы ничего не говорил, только про зависимость решения от задачи.mayorovp
27.03.2018 15:51Не уверен что тут сложнее, а что проще — но как только в задаче появляется явная отметка времени (дата, номер года, день недели) — становится на одну координату больше.
Как программист я бы вовсе не рассматривал модели Крипке как что-то связанное со временем.evkochurov
27.03.2018 16:27Да, слишком замороченный пример я выбрал. Вот другой, более программистский: assert'ы — утверждения, которые должны быть истинны в заданных точках выполнения программы. Часто эти утверждения зависят от истории вычислений. Например, мы хотим сказать, что между точкой А и точкой Б должно пройти не больше X мс. Тут нас не интересует дата-время, а только длительность интервала времени от А до Б. Это тоже формализация понятия о времени, но другая. Все, что я хотел сказать: универсальной формализации нет, она всегда зависит от задачи, когда попроще, когда посложнее.
mayorovp
27.03.2018 16:34Не вижу фундаментальных проблем, тут точно такая же ось времени выходит: f(..., Ta) & f(..., Tb) -> Tb — Ta < X
evkochurov
27.03.2018 22:14Не понял, какой смысл несет предикат f? Для assert'а же достаточно простого Tb — Ta < X. Или даже Tab < X, если в программе уже имеется вычисленная длительность интервала.
maxstroy Автор
27.03.2018 09:45-2Если мы определим состояние объекта, как промежуток времени, в течение которого объект сохраняет какое-то свойство, то надо уточнить, что имеется ввиду не промежуток времени, а множество всех интервалов, которые можно получить из указанного промежутка. Равносильной альтернативой этому утверждению было бы следующее: в любой момент из указанного промежутка времени объект имел одно и то же состояние. Почему я не люблю вторую трактовку данного тезиса? Потому что она опирается на понятие мгновения, которое неизбежно приводит нас к понятию континуума. Моя трактовка опирается на здравый смысл и не требует понятия континуума.
mayorovp
27.03.2018 09:56Вот, о чем я и говорил: у вас появилось свое определение слова «состояние»… Состояние определенно не является промежутком времени.
akryukov
27.03.2018 09:56+1Чтобы описать интервал, вам точно так же нужен момент начала интервала и момент конца интервала. Ну или момент начала интервала и его длительность. В любом случае момент начала должен присутствовать. Поэтому вам все равно придется вводить понятие мгновения, которое, по вашим соображениям, требует понятия континуума.
michael_vostrikov
27.03.2018 10:12Потому что она опирается на понятие мгновения
Она опирается на понятие шага дискретизации. Мгновением считается промежуток в пределах этого шага. То есть, приведенное утверждение равносильно тому, что насколько бы частей мы не поделили исходный промежуток, состояние объекта в пределах любой из них будет таким же. Как видите, никакого континуума не требуется.
maxstroy Автор
27.03.2018 12:44-1Это в вашем воображении, а в воображении соседа — дискретизация иная.
michael_vostrikov
27.03.2018 13:00Ну и что? Состояние-то все равно такое же. Хотя вообще-то дискретизация задается единицами измерения и их взаимосвязями между собой.
И да, чтобы все соседи понимали одинаково, существуют стандарты.
Sinatr
27.03.2018 12:17+1Программирование — это процесс написания алгоритма. Алгоритм — это «упрощенная» логика, решающая определенную задачу в определенных условиях. Не пойму, каким образом специализированный обьект Interval, способный хранить 2 даты и сравнивать себя с другими обьектами (включая другие типы, например Date) вдруг становится вселенской нерешаемой проблемой, с континуумом, веществом и т.д.
Вы, скорее всего, решаете какую-то определенную задачу, и потому вам, возможно, потребуется другой обьект, не Interval. Но я так и не смог понять, для решения какой задачи нужно зачему-то разбивать интервал на континуумы и хранить их.
И не хватает выводов, что с того, что Interval такой, а не другой (который вам нужен)? Чем такое моделирование плохо?maxstroy Автор
27.03.2018 12:33Мы моделируем как можем. В ООП просто нет возможности моделировать множества средствами ООП. Моделирование множеств отдается на откуп программиста. При этом кто-то заявляет, что ООП предназначено для моделирования предметных областей. Именно этот тезис является ложным.
Zenitchik
27.03.2018 12:55+1В ООП просто нет возможности моделировать множества средствами ООП.
Моделирование множеств отдается на откуп программиста.
Взаимоисключающие параграфы.maxstroy Автор
27.03.2018 14:10-1Я бы сказал так: нет штатных методов моделирования множеств. Если есть, сообщите. Если я хочу сообщить, что 70 процентов элементов множества обладают свойством ИКС, то как мне это сделать штатными способами?
lair
27.03.2018 14:16Я бы сказал так: нет штатных методов моделирования множеств.
Есть. В ООП все есть объект, следовательно, штатный метод моделирования множества в ООП — моделирование его как объекта.
Если я хочу сообщить, что 70 процентов элементов множества обладают свойством ИКС
Что значит "сообщить"? Кому? В какой момент?
KodyWiremane
27.03.2018 20:31Правильно ли я понял постановку проблемы в примере со станком: «Как в рамках ООП реализовать хранилище истории состояний объекта (станка) за некоторый интервал времени, с возможностью извлечь из этого хранилища состояние объекта, имеемое им в произвольно заданный с некоторой точностью (например, в сутках) интервал времени?»
maxstroy Автор
27.03.2018 20:47-1Это пример такой задачи, но задача стоит иная. Нужен штатный механизм языка моделирования, который позволит сказать следующее: вот множество объектов, каждый объект данного множества обладает такими свойствами, 30 процентов — такими, 70 процентов — такими. Далее при работе с этим множеством мы берем любой его элемент и система автоматом предлагает нам выбрать свойств из перечисленных выше в порядке приоритета. Если мы не можем этого сделать, она приписывает объекту вероятность быть в таком состоянии или в таком до выяснения обстоятельств. Это есть моделирование в предикатах второго порядка, это крайне необходимо для моделирования, и это сильно меняет парадигму моделирования. С этого момента такие слова, которые нам принес ООП, как «экземпляр этого процесса» исчезнут, а вместо них появятся высказывания на русском языке.
michael_vostrikov
27.03.2018 22:04такие слова, которые нам принес ООП, как «экземпляр этого процесса»
Если вы не понимаете, что означает слово экземпляр, это не значит, что это слово неправильное, и уж тем более что оно должно исчезнуть по вашему желанию.
Вы же сами пишете:
habrahabr.ru/post/343316
Поэтому одно скакание не есть то же скакание, но похожее.
Скакание это процесс?maxstroy Автор
27.03.2018 22:09Извините, я писал об этом много и подробно. Почему нельзя говорить экземпляр этого процесса, — я объяснял неоднократно.
michael_vostrikov
28.03.2018 05:48Как странно. Вас не смущает, что вам неоднократно объясняли, что так обычно и не говорят? Что означает более употребляемая фраза «экземпляр процесса такого-то» и что означает более общая фраза «экземпляр типа» вам тоже объясняли неоднократно. Но вы, несмотря на неоднократность, почему-то эти объяснения игнорируете. Мало того, еще и указываете другим, какие термины должны быть в незнакомой вам предметной области, не разобравшись в значении этих терминов.
Раз уж вы применили некрасивый прием ведения дискуссии «уход от ответа», я напомню вам сам.
Вы писали:
Инструкция — это типовой сценарий (модель процессов, типовой процесс, регламент), последовательность ваших действий — это сценарий, процесс.
Типовой сценарий — это тип. «Обычный» сценарий — это экземпляр. Что тут сложного?
Возвращаясь к вопросу. «Одно скакание» и «другое скакание» — это экземпляры. То, что означает термин «скакание» — это тип. От того, что вы их для себя называете другими словами, значение терминов в другой предметной области не поменяется.maxstroy Автор
28.03.2018 08:07-3Не надо говорить экземпляр процесса «принять заказ», а надо — процесс «принять заказ». Как только от ООПешников я услышу правильные термины, я успокоюсь и пойму, что они понимают, что освободились от своих заблуждений. А пока, извините, не вижу.
michael_vostrikov
28.03.2018 10:24+1Не надо говорить экземпляр процесса «принять заказ», а надо — процесс «принять заказ»
Почему это? Почему вы считаете, что ваши термины правильные, а другие нет?
А по-английски называть тоже никому нельзя, раз лично вы говорите по-русски? При этом ведь тоже другие слова используются. Это не риторический вопрос, ответьте пожалуйста, в чем вы видите разницу.
Хорошо, допустим, некто сказал фразу 'процесс «принять заказ»'. Как понять, он имеет в виду типовой процесс, или нетиповой?
KodyWiremane
27.03.2018 21:32* пардон, промахнулся мимо ветки *
К сожалению, на сегодняшний день, словосочетание «предикат второго порядка» для меня звучит как «абра-кадабра», но для «Примера со станком» я, по крайней мере, в общих чертах могу представить реализацию. Можно попросить сформулировать задачу про множество объектов и 30% и 70% процентов в виде практического примера, «в станках»? Например:
«На текущий момент в бизнес-центре в 100 офисах 100 принтеров: 30 принтеров марки Canine, 70 принтеров марки Epsilon; переходим к формированию поофисного списка…» Оно?maxstroy Автор
27.03.2018 22:53В лесу растут березы и елки. Лесоруб пошел в лес и завалил дерево. Какое дерево он завалил? Либо березу, либо елку. Так и запишем до выяснения обстоятельств. Или более практический пример, который встречается на каждом шагу, но почему-то не замечается. Пусть есть диаграмма в нотации BPMN. Там есть две «дорожки». одна с названием ИС, а вторая помечена как «менегер». С ИС все просто — вот она, а вот где менегер, если менегеров в офисе семь штук? Все дело в том, что дорожки выглядят одинаково, а вот смысл у них разный. У первой дорожки смысл: исполнитель — конкретная ИС, а у второй дорожки смысл иной: исполнитель — какой-то менегер из отдела. Согласитесь, это совсем не одно и то же. Вопрос: какой именно менегер будет делать работу? Какой-то, любой. Это утверждение относительно множества менегеров, а не относительно менегера. Понятно что моделировать утверждения относительно объектов не то же, что моделирование относительно множеств. К сожалению, об этом забывают.
KodyWiremane
27.03.2018 23:15Информация о рубкесодержитИнформация о срубленном деревев нужном количестве;Информация о срубленном деревесодержит полеПорода дерева, которое может принимать одно из значений «Ель», «Берёза», «Не уточнено». Информацию касательно процентного соотношения можно получить черезИнформация о рубке, например. Зависит от того, откуда оно взялось: то ли задание нарубить было в процентах, то ли в лесу столько растёт… То же с менегерами.Информация об исполнителесодержит полеОтдел исполнителя, булево полеНазначен конкретный исполнитель, полеКонкретный исполнительс типом данных, обозначающим сотрудника. Либо без буля, с магическим объектом сотрудника «Любой сотрудник».maxstroy Автор
28.03.2018 05:16-1Вы говорите о программировании в ООП, я же говорю о том, что ООП, декларируя одно, реализует совсем иное. Например, когда мне надо смоделировать менегера, ООП называет его экземпляром этого менегера, когда мне надо смоделировать класс менегеров, у меня нет штатного механизма, когда мне надо смоделировать тип менегеров, ООП называет его менегером. Когда мне надо смоделировать операции на множестве, ООП молчит. Я не понимаю, как в такой каше вообще возможно какое-то моделирование. Именно это я пытаюсь объяснить. ООП не моделирует предметные области, но хорошо подходит для программирования. Главное — не тащить термины ООПв предметную область, чего так любят делать.
lair
28.03.2018 09:01+1Например, когда мне надо смоделировать менегера, ООП называет его экземпляром этого менегера, когда мне надо смоделировать класс менегеров, у меня нет штатного механизма, когда мне надо смоделировать тип менегеров, ООП называет его менегером.
Нет и еще раз нет. Слушайте, уже сколько раз вам говорили: вы просто не понимаете, как работает ООП, зачем вы в него лезете? Вы же не программист, в конце концов, занимайтесь своим моделированием спокойно.
ООП не моделирует предметные области, но хорошо подходит для программирования.
Главное, не забывать, что в процессе программирования может возникать модель предметной области (и чаще всего возникает).
Главное — не тащить термины ООПв предметную область, чего так любят делать.
Кто любит-то? Я, например, неоднократно говорил вам, что тащить термины из любой имплементации, не важно, ООП это или БД (или теория типов, или машинное обучение, или что угодно еще) в предметную область — неправильно, и этого надо избегать.
mayorovp
28.03.2018 09:22когда мне надо смоделировать класс менегеров, у меня нет штатного механизма
Откуда взялось понятие "класс менегеров" в предметной области? Кажется, вы сами только что зачем-то вытащили технический термин в предметную область.
И то же самое по поводу "типа менегера" — в предметной области его тоже не существует. Либо существует, но означает что-то совсем иное, и ООП точно не называет его менегером.
KodyWiremane
28.03.2018 19:11Да, я заглянул в историю публикаций, теперь понимаю так, что вопрос не о возможности реализации «по ООП», а о терминологии. Не являясь гуру программирования, я уточню определения с помощью Википедии:
Объе?кт в программировании — некоторая сущность в компьютерном пространстве, обладающая определённым состоянием и поведением, имеющая заданные значения свойств (атрибутов) и операций над ними (методов).
(Объект (программирование))
Класс — это элемент ПО, описывающий абстрактный тип данных и его частичную или полную реализацию.
Практически класс может пониматься как некий шаблон, по которому создаются объекты — экземпляры данного класса. Все экземпляры одного класса созданы по одному шаблону, поэтому имеют один и тот же набор полей и методов.
В объектно-ориентированной программе с применением классов каждый объект является «экземпляром» некоторого конкретного класса, и других объектов не предусмотрено. То есть «экземпляр класса» в данном случае означает не «пример некоторого класса» или «отдельно взятый класс», а «объект, типом которого является какой-то класс».
(Класс (программирование))
Т. е.Manager manager1 = new Manager();создаёт экземпляр ООП-класса Manager, т. е. создаёт некую численно описывающую менегера структуру в соответствии с шаблоном Manager. Поскольку ООП-классы не являются необходимым компонентом ООП, можно достичь аналогичного эффекта черезObject manager1 = createManager();. Т. е. «экземпляр процесса» — не более чем фигура речи, сленг. Вас, как я понимаю, больше интересовал не ООП-класс (шаблон создания информационной структуры), а класс как множество объектов, имеющих некоторый признак(и), или как набор самих признаков, по которым объект может быть отнесён к этому классу. Так ли это?
Насчёт множеств, насколько я знаю, примитивный тип данныхset— это фактически сахар для битовой карты. Т. е. речь идёт о фиксированном наборе идентификаторов, для каждого из которых хранится информация, присутсствует ли он в этом «множестве» или нет. Если говорить о множестве как о динамически определяемой совокупности объектов… ООП позволяет создавать объекты, трактовкой же их занимается программист, поэтому ничто не мешает создать объект, моделирующий множество: содержащий список членов множества, операции добавления, удаления членов и проверки вхождения значения в множество, пересечения и т. д.
В конце концов, можно создать язык программирования (или диалект), соответствующий вашим терминологическим потребностям. Фреймворк, наконец. А, может, он уже есть.maxstroy Автор
29.03.2018 02:38Вы говорите абсолютно верные вещи. Я могу создать любой нужный фреймворк с терминами, которые приняты в сообществе математиков, где класс — это а-ля множество, а то, что названо классом в ООП, назову типом. Я могу создать все, что угодно, но почему я против того, чтобы гуру ООП говорили о возможности моделирования при помощи ООП? Потому что из-за скошенных терминов в предметные области стали проникать термины, которые не переводятся на русский язык, например, экземпляр этого процесса. Я не знаю, насколько надо не любить ни логику, ни язык, чтобы так говорить, но программист не замечает всей дикости этого высказывания! И от этого возникают такие искажения в мозгу, которые уже не лечатся. Посмотрите выше и вы поймете, что программисты реально думают, что такой термин допустим в русском языке и имеет какой-то смысл! Причина — в ООП!
michael_vostrikov
29.03.2018 05:34+2термины, которые не переводятся на русский язык, например, экземпляр этого процесса
программисты реально думают, что такой термин допустим в русском языкеНу сколько можно говорить. Такое словосочетание может иметь смысл в некотором контексте. Это не является общепринятым термином, это отсылка к нему в редуцированном виде. Правильный термин другой. Почему вы продолжаете высказывать заведомо неверные утверждения?
Я не знаю, насколько надо не любить ни логику, ни язык
Комменты и выше и в других статьях написаны русским языком. Насколько надо не любить ни логику, ни язык, чтобы не понимать одних и тех же доводов, повторенных много раз?
Вы высказываете необоснованные утверждения и уходите от ответа, когда спрашивают о причинах или приводят противоречащие этому примеры.
Вы задаете вопросы, и получив ответы, продолжаете задавать их же в дальнейшем, хотя не приводите контр-аргументов, почему ответ вам не подходит.
Вы даже не смогли сформулировать ответ на вопрос, в чем вы видите различия между другими названиями на одном языке и названиями на другом языке.
Что там про логику и владение языком?
lair
29.03.2018 10:58Потому что из-за скошенных терминов в предметные области стали проникать термины
Нет, термины в предметные области стали проникать из-за недостаточной аккуратности в процессе разработки.
Вы думаете, термины "таблица БД" и "запись БД" в бизнес-требованиях чем-то лучше "класса"?
Посмотрите выше и вы поймете, что программисты реально думают, что такой термин допустим в русском языке и имеет какой-то смысл!
В русском языке допустим любой "термин", потому что в языке терминов нет, они есть только в предметной области.
maxstroy Автор
29.03.2018 16:08-1Никто не говорит процесс «принять заявку», вместо этого — экземпляр процесса «принять заявку» Вы разницу видите?! Я вижу. А вместо того, чтобы сказать тип процессов вы говорите процесс! Разница есть?
Zenitchik
29.03.2018 17:25Строго говоря, Вы правы. Но от сокращения смысл не страдает. Дураку же ясно, что подразумевается тип процесса, а короче на два слога — т.е. вдвое.
lair
29.03.2018 18:05Вы разницу видите?
Разницу между чем и чем? Из вашего комментария даже не понятно, кто как говорит, и как по-вашему надо.
вместо того, чтобы сказать тип процессов вы говорите процесс
Я? Нет, я так не говорю.
maxstroy Автор
29.03.2018 06:46-1Собственно, ответ ниже подтверждает мои слова о том, что адепт ООП не понимает коллизий в своих высказываниях. Когда я спрашиваю, чем экземпляр процесса отличается от процесса, мне говорят, что ничем. Я спрашиваю: по логике это значит, что можно заменить термин экземпляр этого процесса на процесс. Но мне отвечают, что в ООП это сделать нельзя. И это все наравне с якобы пониманием коллизии. Противоречие самому себе — это круто! Иногда мне говорят, что экземпляр процесса — это воплощение процесса. Это другая история — под процессом начинают понимать тип процессов. Это еще одна проблема адепт ООП не различает объект и тип объектов. Или различает, но тип называет именем объекта, а объект — именем объекта с приставкой экземпляр этого. При этом заменить термины нельзя, потому что это ООП, детка.
michael_vostrikov
29.03.2018 09:09+1чем экземпляр процесса отличается от процесса, мне говорят, что ничем
Вам говорят, что то, что вы называете "просто процесс", в другой системе терминов называется "экземпляр типа 'Процесс'".
Я спрашиваю: по логике это значит, что можно заменить термин экземпляр этого процесса на процесс.
Нет, вы не говорили о замене одного правильного термина на другой. Вы говорили, что термин "экземпляр" неправильный. Спорят с вами по поводу правильности, а не по поводу замены.
Кстати, почему вы продолжаете употреблять выражение "экземпляр этого процесса", если вам сказали, что в отрыве от контекста оно не употребляется? Правильная форма — "экземпляр типа 'Процесс'" или "экземпляр этого типа", в крайнем случае "экземпляр процесса '<более конкретное название типа процессов>'". Если вы собираетесь снова обсуждать это в дальнейших статьях, используйте одну из этих форм, чтобы быть понятым другими.
Но мне отвечают, что в ООП это сделать нельзя.
Не могли бы вы привести ссылку, где именно вам такое сказали?
Вам говорили о том, что термин "экземпляр" корректен, и что отказ от него будет вызывать неоднозначность в выражениях вида 'процесс «принять заказ»'. На вопрос, как устранить неоднозначность в вашей системе терминов, вы тоже ответить не смогли.
но тип называет именем объекта, а объект — именем объекта с приставкой экземпляр этого
Вы пишете:
"Поверхность – это проекция 4-Д объема на пространство в виде поверхности, ограничивающей объем."
Здесь вы явно говорите не о конкретной поверхности, следовательно, о типовой.
Почему вы типовое понятие называете именем объекта (а именно словом "поверхность"), если считаете, что это неправильно?
И нет, тип называют именем с приставкой "тип", а объект именем с приставкой "экземпляр". Если это не ясно из контекста, либо если ясно, но нужно сослаться на другой смысл.
P.S. Если у вас есть возражения, не могли бы вы высказывать их прямо, а не косвенно через комментарий другого человека. Это к вопросу о вашей логике.
lair
27.03.2018 23:21Это утверждение относительно множества менегеров, а не относительно менегера
А вот кстати нет. Это утверждение относительно неизвестного на данный момент объекта, удовлетворяющего некоему критерию (в данном случае — "менеджер из отдела").
Ну и как бы все равно не понятно, какую задачу вы решаете.
Hedgehogues
А за что так активно минусуют человека?
Danov
Философию не любят. Сложно и непрактично.
maxstroy Автор
Тут не в философии дело. Когда речь идет о предикатах, — это логика. Такое чувство, что с логикой не дружат.
mayorovp
Этот человек отказывается использовать общепринятые определения и придумывает свои по любому поводу. Да еще и настолько плохо их формулирует, что высказываемые им утверждения порой противоречат его же определением, но он этого не замечает потому что у него давно придумана своя логика, отличная от общепринятой.
maxstroy Автор
Скажите, где ошибка в данном тексте? Хотя, спасибо за отзыв, был полезен!
mayorovp
Ну вот например:
Разумеется, ответ на этот вопрос получить можно, ведь интервал с 1956 по 1958 входит в интервал с 1939 по 1990. Из истинности предиката на множестве следует его истинность на любом подмножестве.
Но у вас, конечно же, свои определения слов "существует", "интервал", "время" и "предикат"...
maxstroy Автор
Интервал множество???? То есть, в ООП он моделируется классом?? вы уверены? На мой взгляд, когда ИТ специалист говорит об интервале, он говорит об объекте, а не о множестве объектов. Если же речь идет о множестве, то как оно моделируется при помощи ООП?
mayorovp
Да, интервал — это разновидность множества. В общепринятых определениях, конечно же.
maxstroy Автор
Фокус в том, что в ООП интервал моделируется как объект, а не как множество. Из этого делается вывод, что интервал — объект. Если это не так, то расскажите, как в ООП моделируются множества, и интервалы времени в частности.
lair
В ООП, напоминаю, все — объект. Даже множество — объект.
maxstroy Автор
Так как моделируется множество Интервал?
lair
Объектом с поведением, удовлетворяющим требованиям.
maxstroy Автор
Спасибо, каждый останется при своем мнении. ИМХО, это не модель множества. Тогда не понятно, что такое сеты и прочая интересная шняга в ООП
lair
И что?
В ООП нет "сетов и прочей интересной шняги", они есть в библиотеках тех или иных языков и платформ.
akryukov
А вам какое множество, дискретное или непрерывное?
lair
Между этими двумя вопросами нет никакой связи.
С "помощью ООП" моделируется (в данном случае) интервал, а не множество. В этой модели могут быть определены предикаты "входит".
maxstroy Автор
И как моделируется множество Интервал в ООП?
lair
https://habrahabr.ru/post/352034#comment_10725810
maxstroy Автор
ИМХО, это не модель множества. Тогда не понятно, что такое сеты и прочая интересная шняга в ООП
retran
Объектом, содержащим значения концов интервала и признаками открытости/закрытости этих концов. Точно по определению из математики.
retran
А еще я напомню, что множество — это не набор значений, а набор правил определяющих вхождение того или иного значения в данное множество. Опять же, из математики. Вхождение значения в интервал, как подсказывается кэп, определяется как a < value < b, где a, b — концы интервала.
maxstroy Автор
Итак, как в ООП моделируются предикаты второго порядка?
lair
Так же, как и любая другая сущность или операция предметной области.
retran
Паттерн «Спецификация» в помощь.
retran
Интервал — это множество. У которого по определению есть предикат «входит» для числа. Из него легко вывести предикат для подмножеств. Если предиката нету — это не интервал, а просто два числа на отрезке.
mayorovp
Спасибо что изменили свой комментарий после того как я на него ответил. Изначально там было только первые два слова…
Когда я как ИТ специалист говорю об интервале, я говорю о математическом понятии. Совершенно не обязательно что я вообще буду вводить в программе отдельный класс или объект «интервал», это слишком мелкая абстракция; скорее всего этот интервал так и останется в виде двух переменных.
Кроме того, не забывайте о контексте. Мой комментарий выше был про логику, а не про программирование.
maxstroy Автор
Я же пишу про моделирование. ООП претендует на стандарт моделирования предметных областей. Я пытаюсь объяснить, почему это — ложь.
mayorovp
И что именно мешает ООП моделировать предметные области?
maxstroy Автор
Как видите, ООП не моделирует предметные области. По крайней мере lair так считает.
lair
Пожалуйста, не надо мне приписывать того, что я не говорил.
mayorovp
Он говорил что ООП не претендует на стандарт моделирования предметных областей. Что не мешает использовать его в качестве одного из инструментов моделирования предметных областей.
maxstroy Автор
Так- то да, только им пользоваться нельзя, потому что не получается моделировать утверждения штатным образом, про которые я пишу. Или вы покажете мне раздел документации, в котором сказано, как моделировать предикаты второго порядка?
mayorovp
Это вы выдумали какой-то «штатный образ». Те же самые утверждения прекрасно моделируются если использовать штатные способы ООП вместо ваших.
lair
Удивительное дело, пользоваться нельзя, а разработанные системы — есть.
Что такое "штатный образ"?
lair
Нет, не претендует. Вы выдумали себе пугало и боретесь с ним.
lair
За необоснованные утверждения.
maxstroy Автор
Какие необоснованные утверждения в данной статье?
lair
Например, вот вам два:
И вот вам третье:
Дальше, извините, копировать лень.