Как мы моделируем предметную область в предикатах второго порядка и не замечаем этого -12


Любая модель обладает ограниченной точностью. Чем более точную модель надо построить, тем больше информации для этого придется хранить. Если есть возможность свернуть массив данных по какому-то из критериев, то такая свертка позволяет резко сократить объем хранимой информации. Однако, такая свертка не моделируется штатными способами моделирования, потому что требует моделирования высказываний одновременно и относительно множеств объектов, а не относительно объектов этих множеств. Фактически, нам нужен инструмент для моделирования как предикатов первого порядка, так и предикатов второго порядка.


Поясню на самом распространенном примере. Когда мы пишем, что станок был выпущен в 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):

  1. Hedgehogues
    /#10725680

    А за что так активно минусуют человека?

    • Danov
      /#10725724 / -3

      Философию не любят. Сложно и непрактично.

      • maxstroy
        /#10725736 / +1

        Тут не в философии дело. Когда речь идет о предикатах, — это логика. Такое чувство, что с логикой не дружат.

    • mayorovp
      /#10725742

      Этот человек отказывается использовать общепринятые определения и придумывает свои по любому поводу. Да еще и настолько плохо их формулирует, что высказываемые им утверждения порой противоречат его же определением, но он этого не замечает потому что у него давно придумана своя логика, отличная от общепринятой.

      • maxstroy
        /#10725744

        Скажите, где ошибка в данном тексте? Хотя, спасибо за отзыв, был полезен!

        • mayorovp
          /#10725748 / +2

          Ну вот например:


          Можно ли интерпретировать запись о том, что станок существует с 1939 по 1990 год как утверждение не о множестве, а как утверждение об интервале времени? Да, можно. Но с такой трактовкой нельзя получить ответ на вопрос: существовал ли станок с 1956 по 1958 год?

          Разумеется, ответ на этот вопрос получить можно, ведь интервал с 1956 по 1958 входит в интервал с 1939 по 1990. Из истинности предиката на множестве следует его истинность на любом подмножестве.


          Но у вас, конечно же, свои определения слов "существует", "интервал", "время" и "предикат"...

          • maxstroy
            /#10725756

            Интервал множество???? То есть, в ООП он моделируется классом?? вы уверены? На мой взгляд, когда ИТ специалист говорит об интервале, он говорит об объекте, а не о множестве объектов. Если же речь идет о множестве, то как оно моделируется при помощи ООП?

            • mayorovp
              /#10725760 / -1

              Да, интервал — это разновидность множества. В общепринятых определениях, конечно же.

              • maxstroy
                /#10725772 / -1

                Фокус в том, что в ООП интервал моделируется как объект, а не как множество. Из этого делается вывод, что интервал — объект. Если это не так, то расскажите, как в ООП моделируются множества, и интервалы времени в частности.

                • lair
                  /#10725802

                  Из этого делается вывод, что интервал — объект.

                  В ООП, напоминаю, все — объект. Даже множество — объект.

                  • maxstroy
                    /#10725806

                    Так как моделируется множество Интервал?

                    • lair
                      /#10725810

                      Объектом с поведением, удовлетворяющим требованиям.

                      • maxstroy
                        /#10725828

                        Спасибо, каждый останется при своем мнении. ИМХО, это не модель множества. Тогда не понятно, что такое сеты и прочая интересная шняга в ООП

                        • lair
                          /#10725836

                          Спасибо, каждый останется при своем мнении. ИМХО, это не модель множества.

                          И что?


                          Тогда не понятно, что такое сеты и прочая интересная шняга в ООП

                          В ООП нет "сетов и прочей интересной шняги", они есть в библиотеках тех или иных языков и платформ.

                    • akryukov
                      /#10726498

                      А вам какое множество, дискретное или непрерывное?

            • lair
              /#10725800

              Интервал множество???? То есть, в ООП он моделируется классом??

              Между этими двумя вопросами нет никакой связи.


              Если же речь идет о множестве, то как оно моделируется при помощи ООП?

              С "помощью ООП" моделируется (в данном случае) интервал, а не множество. В этой модели могут быть определены предикаты "входит".

              • maxstroy
                /#10725812 / -1

                И как моделируется множество Интервал в ООП?

                • retran
                  /#10725842

                  Объектом, содержащим значения концов интервала и признаками открытости/закрытости этих концов. Точно по определению из математики.

                • retran
                  /#10725852

                  А еще я напомню, что множество — это не набор значений, а набор правил определяющих вхождение того или иного значения в данное множество. Опять же, из математики. Вхождение значения в интервал, как подсказывается кэп, определяется как a < value < b, где a, b — концы интервала.

                  • maxstroy
                    /#10726418

                    Итак, как в ООП моделируются предикаты второго порядка?

                    • lair
                      /#10726594

                      Так же, как и любая другая сущность или операция предметной области.

                    • retran
                      /#10727398

                      Паттерн «Спецификация» в помощь.

              • retran
                /#10725838 / +1

                Интервал — это множество. У которого по определению есть предикат «входит» для числа. Из него легко вывести предикат для подмножеств. Если предиката нету — это не интервал, а просто два числа на отрезке.

            • mayorovp
              /#10725964

              Спасибо что изменили свой комментарий после того как я на него ответил. Изначально там было только первые два слова…

              Когда я как ИТ специалист говорю об интервале, я говорю о математическом понятии. Совершенно не обязательно что я вообще буду вводить в программе отдельный класс или объект «интервал», это слишком мелкая абстракция; скорее всего этот интервал так и останется в виде двух переменных.

              Кроме того, не забывайте о контексте. Мой комментарий выше был про логику, а не про программирование.

              • maxstroy
                /#10726546 / -1

                Я же пишу про моделирование. ООП претендует на стандарт моделирования предметных областей. Я пытаюсь объяснить, почему это — ложь.

                • mayorovp
                  /#10726560

                  И что именно мешает ООП моделировать предметные области?

                  • maxstroy
                    /#10726860 / -2

                    Как видите, ООП не моделирует предметные области. По крайней мере lair так считает.

                    • lair
                      /#10726878 / +1

                      Пожалуйста, не надо мне приписывать того, что я не говорил.

                    • mayorovp
                      /#10726900

                      Он говорил что ООП не претендует на стандарт моделирования предметных областей. Что не мешает использовать его в качестве одного из инструментов моделирования предметных областей.

                      • maxstroy
                        /#10726910

                        Так- то да, только им пользоваться нельзя, потому что не получается моделировать утверждения штатным образом, про которые я пишу. Или вы покажете мне раздел документации, в котором сказано, как моделировать предикаты второго порядка?

                        • mayorovp
                          /#10726930 / +1

                          Это вы выдумали какой-то «штатный образ». Те же самые утверждения прекрасно моделируются если использовать штатные способы ООП вместо ваших.

                        • lair
                          /#10726940

                          только им пользоваться нельзя

                          Удивительное дело, пользоваться нельзя, а разработанные системы — есть.


                          не получается моделировать утверждения штатным образом

                          Что такое "штатный образ"?

                • lair
                  /#10726586

                  ООП претендует на стандарт моделирования предметных областей.

                  Нет, не претендует. Вы выдумали себе пугало и боретесь с ним.

    • lair
      /#10725792

      За необоснованные утверждения.

      • maxstroy
        /#10725794

        Какие необоснованные утверждения в данной статье?

        • lair
          /#10725808

          Например, вот вам два:


          Можно ли интерпретировать запись о том, что станок существует с 1939 по 1990 год как утверждение не о множестве, а как утверждение об интервале времени? Да, можно. (1) Но с такой трактовкой нельзя получить ответ на вопрос: существовал ли станок с 1956 по 1958 год? (2) Такой способ моделирования не используется.

          И вот вам третье:


          Беда нашего языка в том, что невозможно разделить эти две разные трактовки одних и тех же слов.

          Дальше, извините, копировать лень.

  2. ondister
    /#10725886

    Кандрашина Е.Ю., Литвинцева Л.В., Поспелов Д.А. Представление знаний о времени и пространстве в интеллектуальных системах. Я когда-то начал с этого...

  3. maxstroy
    /#10725948 / -2

    К сожалению, ни один комментатор не объяснил, что такое класс в ООП (в матлогике — это множество). Как множества моделируются в ООП и, если интервал времени — это множество, то почему оно моделируется датой начала и датой конца?

    • mayorovp
      /#10725956 / +1

      Класс в ООП и множество в матлогике теории множеств — это совершенно разные вещи.

      Множество является фундаментальным понятием; такие понятия вводятся не конструктивно, а аксиоматически. А потому они не могут быть выражены (конкретными) классами, только интерфейсами.

      > Как множества моделируются в ООП

      Полностью — никак, потому что существует бесконечное количество невычислимых множеств; поэтому модели ограничиваются лишь конкретными разновидностями множеств.

      Наиболее общая разновидность — вычислимое множество — в ООП становится интерфейсом с одним методом вроде Contains, который проверяет принадлежность элемента множеству.

      Однако обычно используется намного более узкий тип множеств — конечное множество, в таком случае в интерфейсе появляется метод получения количества элементов и способ перечисления этих элементов.

      Интервал же — вполне конкретная конструкция, которую без труда можно выразить классом. Но интерфейс конечного множества интервал обычно не реализует, потому что он, как правило, является бесконечным множеством.

      • maxstroy
        /#10726420

        Спасибо за ответ! Но это не совсем то, что я хотел спросить. Меня интересовал вопрос моделирования предикатов второго порядка в ООП,

        • mayorovp
          /#10726454

          Все зависит от задачи. Проблема тут в том, что в математике с предикатом второго порядка можно сделать кучу разных вещей, которые будут невычислимы в общем случае — а потому модель будет зависеть от того что с этими предикатами второго порядка мы будет делать.

          В простейшем же случае предикат второго порядка напрямую моделируется функцией второго порядка.

          • maxstroy
            /#10726552

            Главное — я утверждаю, что в ООП нет штатного механизма моделирования таких тезисов. Более ничего.

            • mayorovp
              /#10726562

              Осталось понять почему это плохо. Вот ни разу я еще не сталкивался с необходимостью программного моделирования предиката второго порядка…

              • maxstroy
                /#10726872

                Я сталкиваюсь с этой необходимостью постоянно. Например, мне надо сказать, что исполнителем данной роли будет кто-то из отдела кадров, не называя, кто именно. Это утверждение в предикатах второго порядка, которое я не могу смоделировать при помощи ООП штатными средствами.

                • lair
                  /#10726882

                  Это утверждение в предикатах второго порядка, которое я не могу смоделировать при помощи ООП штатными средствами.

                  Серьезно?


                  executor = hrDepartment.anyEmployee;

                • mayorovp
                  /#10726906 / +1

                  Если утверждение сделано в предикатах второго порядка — это совершенно не означает что его нужно моделировать как произвольный предикат второго порядка!

                  • maxstroy
                    /#10726914

                    Покажите мне раздел документации, в котором сказано, как при помощи ООП моделируются предикаты второго порядка.

                    • evkochurov
                      /#10726926 / +1

                      Не надо лезть в ООП со вторым порядком, с первым надо сначала разобраться…

                  • evkochurov
                    /#10726920

                    Нет, это обычное первопорядковое утверждение с квантором существования, автор просто плохо разбирается в формальной логике.

                    • mayorovp
                      /#10726932

                      Любое утверждение первого порядка может быть сведено к утверждению второго порядка. А любая разрешимая задача может быть сведена к неразрешимой, чем автор и занимается :-)

    • lair
      /#10726002

      такое класс в ООП

      Начнем с первого вопроса: а зачем?


      Как множества моделируются в ООП

      Так, как этого требует задача. Разные задачи приводят к разным моделям.


      если интервал времени — это множество, то почему оно моделируется датой начала и датой конца

      А кто вам сказал, что интервал времени моделируется датой начала и конца?

    • michael_vostrikov
      /#10726342

      ни один комментатор не объяснил, что такое класс в ООП

      Вам это объясняли неоднократно в предыдущих статьях.


      если интервал времени — это множество, то почему оно моделируется датой начала и датой конца?

      Оно может моделироваться датой начала и датой конца. А может по-другому.
      Почему может? Потому что это правило. Применительно к станкам это правило вида "станок существовал на протяжении всего указанного периода и в любой интервал времени между указанными датами".

  4. michael_vostrikov
    /#10726340

    Альтернативой этому высказыванию было бы хранение информации о всех возможных интервалах, в течение которых станок был признан существующим. Но все возможные интервалы времени на протяжении этого срока даже с шагом дискретизации в сутки – это огромный массив данных.

    Ваши "все возможные интервалы" с некоторым шагом дискретизации принципиально ничем не отличаются от одного возможного интервала "1939 — 1990". Потому что и там и там считается, что "станок существовал на протяжении всего указанного периода и в любой интервал времени" между событиями дискретизации.


    Вы заметили, что работа с датами в запросах, которые мы строим, отличается от работы с данными другого типа?

    Работа с интервалами дат ничем не отличается от работы с интервалами расстояний.

    • maxstroy
      /#10726374

      Верно, потому что есть расстояния как объекты — они неделимы и есть расстояния, которые делимы, потому что они по сути, как и вещества — не есть объекты, а есть множества. Об этом и статья. Надо делить интервалы времени, которые неделимы от интервалов, которые делимы. Объекты надо отделить от мнложеств. Но, я так понял, это как раз вы и не поняли. Кроме того, я так и не услышал, как в ООП моделируются предикаты второго порядка.

      • Deosis
        /#10726390

        интервалы времени, которые неделимы

        Приведите пример неделимого интервала, потому что для меня интервал непрерывен, и его всегда можно разделить.
        Например любой интервал можно разделить на два: от начала и до середины, от середины и до конца.

        • maxstroy
          /#10726414

          Если для вас все интервалы делимы, то вы имеете дело со множествами. Не более. Но, если мы увидим неделимые интервалы, то это будут объекты. И вот вопрос: как в ООП построена работа со множествами?

          • Mikluho
            /#10726486 / +1

            Ответ на вопрос «как в ООП построена работа со множествами?» — никак. ООП не про это.
            ООП, как и любая другая парадигма программирования, описывает методику моделирования абстракций. С точки зрения программирования, и интервал и множество — это в первую очередь абстракции. И любой нормальный программист смоделирует их так, как это будет удобно и полезно в рамках выбранной парадигмы.

            ps
            «Любой нормальный» — сильное утверждение, но это моё имхо.

            • maxstroy
              /#10726504 / -1

              Если верно то, что вы говорите, то ООП не может претендовать на моделирование предметных областей, о чем я постоянно говорю.

              • mayorovp
                /#10726526

                Вы путаете разные виды моделирования. Модель может быть математической, а может быть программной. ООП не претендует на построение первых, но успешно делает вторые.

              • Mikluho
                /#10726528

                Тогда у меня для вас печальная весть: язык наш тоже ничего такого не определяет. Он тоже лишь «описывает методику моделирования абстракций» и даёт некоторое количество примитивов. Сам по себе он «не может претендовать на моделирование предметных областей». Но вы зачем то им пользуетесь…

          • michael_vostrikov
            /#10726644 / +2

            Если для вас все интервалы делимы, то вы имеете дело со множествами

            Это если считать, что множество это не объект. А если считать, что это объект, то проблем никаких не возникает.

      • lair
        /#10726590

        Надо делить интервалы времени, которые неделимы от интервалов, которые делимы. Объекты надо отделить от мнложеств.

        Кому надо?

      • michael_vostrikov
        /#10726640 / +1

        потому что есть расстояния как объекты — они неделимы и есть расстояния, которые делимы

        Нет таких видов расстояний. Все из чего-то состоит, до пределов единиц квантования. Это никак не мешает нам выделять объекты и работать с ними.

        как в ООП моделируются предикаты второго порядка.

        Определение
        In mathematical logic, a second-order predicate is a predicate that takes a first-order predicate as an argument.

        Из чего следует, что самый простой способ — это моделировать функцией, которая принимает в качестве аргумента другую функцию, которая моделирует предикат первого порядка. Также есть понятие «обобщенные типы», когда один тип является аргументом в определении второго типа.

  5. evkochurov
    /#10726368

    Формально эта информация записывается так: для любого элемента множества временных интервалов с 1939 года по 1990 верно следующее: в течение этого интервала времени существовал указанный станок. Это и есть моделирование в предикатах второго порядка.

    Вы хотите сказать, что «временной интервал с А по Б» — это предикат? Какой он арности и на каких типах аргументов определен?

    • maxstroy
      /#10726370

      Спасибо за коммент! Я говорю не об интервале времени. Интервалы времени в ИС не моделируются. В этом вся проблема. Моделируются классы интервалов. Когда мы пишем, что объект А существовал с такого-то по такое, мы имеем ввиду, что он существовал в любой интервал из указанного, а не просто существовал указанный интервал. Это ровно как с веществом, когда мы говорим, что в стакане вода, мы имеем ввиду не объект, а множество всех объемов, которые можно выделить из объема стакана. В любом из выделенных объемов есть вода. Мы так думаем, но не понимаем этого. Об этом статья. Разница между временным интервалом1 и временным интервалом2, между объектом и веществом именно в том, что в одном случае мы говорим об объекте, а во втором — о множествах объектов. Давай сначала договоримся об этом тезисе.

      • Mikluho
        /#10726460 / +1

        А зачем нам договариваться об этом тезисе?
        Вы очень хотите убедить всех присутствующих в важности такого разделения между объектом и множеством, но совсем не объясняете, зачем. Зачем вводить сложность там, где реальность моделируется более простыми средствами?
        И почему это вдруг в ИС не моделируются интервалы?.. И чём принципиальная разница, с точки зрения программирования, утверждений "просто существовал указанный интервал" и "он существовал в любой интервал из указанного"?

        • maxstroy
          /#10726492 / -1

          Если вы не различаете красный и синий, это не значит, что все не различают. Если вам различия не интересны, то для вас нет вопроса и нет ответа.

          • Mikluho
            /#10726518

            Вот, вы опять вместо ответа на вопрос, начинаете вилять словами.
            Мне интересны различия, особенно, если они а) внятны и б) полезны.
            Ваши термины не блещут ни тем, ни другим.
            Если у нас есть кусок ткани синего цвета, то из свойств нам полезны будут размер, конкретный тон синего, тип ткани, форма… И лишь в некоем гипотетическом крайнем случае будет важно то, что все нити в этом куске синего цвета, и, о боже, любой фрагмент любой нити тоже синего цвета.
            Но вопрос остаётся вез ответа — зачем делать этой крайний случай краеугольным?

      • mayorovp
        /#10726500

        Это ровно как с веществом, когда мы говорим, что в стакане вода, мы имеем ввиду не объект, а множество всех объемов, которые можно выделить из объема стакана.

        Нет, это вы имеете в виду множество всех объемов. Я имею в виду именно стакан.

        • maxstroy
          /#10726514

          Если вы имеете ввиду стакан воды, то это объект неделимый, как и промежуток времени может быть неделимым, как и расстояние — тоже. В языке нет маркера, который бы говорил нам. о чем идет речь: об объекте, или о множестве. Из-за этого проблемы с пониманием и моделированием.

          • mayorovp
            /#10726532

            Физическая неделимость объекта не означает что его нельзя поделить мысленно.

            А промежутки всегда делимы.

            • maxstroy
              /#10726558

              Нельзя поделить машину на части и получить много разных машин, а время — можно. В чем разница?

              • mayorovp
                /#10726564 / +1

                Но можно поделить машину на части и получить много частей машины.

              • michael_vostrikov
                /#10726664

                Зато палку можно поделить на 2 части и получить 2 палки.
                Можно поделить машину на коврик и машину.
                А разница в том, что есть правило, позволяющее назвать нечто определенным термином.

                • maxstroy
                  /#10726694 / -1

                  Машина не делится на две машины, а интервал времени делится на два интервала. Собственно, если это не понятно, то не стоит тратить время.

                  • michael_vostrikov
                    /#10726874

                    Ну не делится, и что? Почему то, что делится на составные части не может быть объектом? Даже термин такой есть — составной объект.

                    Поезд зато делится на 2 поезда. Поезд теперь не объект, с ним нельзя работать как с одним целым? Дом можно разобрать и построить 2 дома. Это тоже не объект?

                    Машина в контексте обсуждения является квантом измерения машин.
                    Кроме того, предлагаю вам подумать над следующим примером. Машина без коврика это машина? А без колеса? Может человек сказать «у меня есть машина, надо только колесо купить»? А без двигателя? А если скажем взять 100 одинаковых машин, взять с каждой по одной запчасти, и собрать из них еще одну машину? Получится, что из 100 машин можно сделать 101 машину поменьше.

      • lair
        /#10726598 / +1

        Интервалы времени в ИС не моделируются.

        Вы хотели пример необоснованного утверждения? Вот оно, пожалуйста. Очевидно, интервалы времени моделируются — например, в ИС, отвечающей за учет имущества, "имущество было на балансе в интервал с… по ...".

      • evkochurov
        /#10726670 / +2

        Я говорю не об интервале времени

        Разве?
        Формально эта информация записывается так: для любого элемента множества временных интервалов с 1939 года по 1990 верно следующее: в течение этого интервала времени существовал указанный станок. Это и есть моделирование в предикатах второго порядка.

        Так не пойдет. Если Вы хотите нас убедить, что это второпорядковое утверждение, покажите, где тут квантор по предикатам или второпорядковый предикат. Иначе все статья — пшик, начиная с заголовка.

        • maxstroy
          /#10726880

          Если мы понимаем под временным интервалом неделимый отрезок времени, что еще никто и никогда не понимал, то тогда для этих отрезков мы можем построить высказывание: Для любого отрезка верно: Объект существует. при этом арность — унарная, тип переменной — логический, значения: да, или нет.

          • evkochurov
            /#10726916

            Это бессмысленное утверждение, т.к. кванторная переменная не используется в подкванторном выражении. Это демонстрирует, к сожалению, непонимание даже логики первого порядка, что уж говорить о втором…

            • maxstroy
              /#10726946

              Спасибо большое! Я специально разбирался относительно высказываний и у меня вопрос: если мне надо сказать: такой-то процент элементов данного множества обладает такими-то свойствами — это высказывание в предикатах какого порядка? В частном случае я могу сказать — все сто процентов объектов обладают данным свойством.

              • evkochurov
                /#10727124

                Поскольку на Хабре не принято уходить от ответа, сделаю оговорку: Вам трудно будет его правильно понять, не разбираясь в формальной логике.

                Это высказывание первого порядка, т.к. «множество» и «свойство элементов множества» — равноправные элементы универса. Именно непонимание того, что такое универс в логике предикатов, Вас подводит. Хотя, конечно, не только это.

                Для формулирования такого высказывания достаточно включить в теорию арифметику, функцию взятия мощности множества и предикат равенства. Либо, если для решаемой задачи это слишком сильная теория и достаточно выражать проценты с заданной точностью, то сойдет и трехместный предикат ПроцентноеСоотношениеМножеств(Множество, Множество, Процент).

                • lair
                  /#10727132

                  Можно, кстати, примитивный вопрос? Чем плоха (или почему недопустима) трактовка предиката как функции, возвращающей ответ из множества {0, 1}?

                  • evkochurov
                    /#10727184

                    Тем, что этот взгляд закрывает путь к пониманию неклассических логик, где предикаты в принципе не имеют значений, ни истинностных, ни из заданного множества. А для программиста, реализующего заданную теорию в коде, это вполне нормальная трактовка, если она дает ему какие-то бонусы, по производительности, например.

                    Ну и надо понимать, что такие функции делают истинностные значения термами и, как следствие, элементами универса. Т.е. Вы получите всякие странности, например, кванторы будут бегать не только по объектам, но и по истинностным значениям. И чтобы это не приводило к проблемам, во всех формулах постоянно придется ставить ограничения на типы аргументов предикатов и функций.

                    • lair
                      /#10727190

                      А для программиста, реализующего заданную теорию в коде, это вполне нормальная трактовка, если она дает ему какие-то бонусы, по производительности, например.

                      Ну то есть типовая для многих языков программирования формулировка predicate(T) = function T -> bool (где T — это тип элемента в множестве) для практических задач вполне разумна?

                      • evkochurov
                        /#10727236

                        Конечно.

                        • lair
                          /#10727250

                          Спасибо. Это позволяет ответить на повторяющийся тут вопрос "как в ООП представляются предикаты второго порядка" — как функции второго порядка, или, в общем случае, функции высшего порядка, что давно является решенной задачей.


                          Естественно, это все верно с оговоркой "если для конкретной задачи это оправданно и достаточно".

                          • retran
                            /#10727418

                            Справедливости ради, функции высшего порядка — это не классическое ООП.

                            А вот «Спецификация» как по мне, вполне себе отвечает запросу автора.

                            • lair
                              /#10727538

                              Блин, двух слов не хватило: "так же, как функции высшего порядка". То есть пуристы берут компонуемые объекты (по тому или иному паттерну), реалисты берут ОО-язык, в котором есть ФВП, и веселятся.

                              • retran
                                /#10727570

                                Не, ну так можно вспомнить Пролог, где предикаты второго порядка есть в чистом виде как first-class citizen, или Хаскелль с его монадами.

                                Исходный тезис автора — в ООП не моделируются предикаты второго порядка. Это, очевидно, неправда.

                • maxstroy
                  /#10727152

                  Спасибо еще раз! Я бы очень хотел видеть, как моделируются подобные вещи в ООП. К сожалению, я не нашел ни раздела в документации ни в книгах по ООП раздела, посвященного моделированию утверждений, которые я хочу смоделировать. Это: для любого объекта данного множества верно следующее: И на основе этого появляется возможность работать с отрезками времени как с элементами множества. А без этого утверждения не должно быть такой возможности. Тогда я смогу развести по сторонам утверждения относительно интервалов времени и утверждения относительно множеств интервалов.

                  • lair
                    /#10727168 / +1

                    Что вообще вы понимаете под "моделирование в ООП утверждений"? ООП — (преимущественно) императивная парадигма, она оперирует инструкциями, а не утверждениями. Задача же "если для любого объекта в X верно Y, то" решается тривиальным if (x.All(Y)) then.

                    • maxstroy
                      /#10727200 / -2

                      Не, я не про это. При помощи мясорубки можно гвозди забивать. Меня интересует предназначение ООП.

                      • lair
                        /#10727208 / +2

                        Предназначение ООП — объектно-ориентированного программирования, частного случая программирования вообще — это создавать программы.

                • evkochurov
                  /#10727154

                  Но все это пустое, т.к. понятие о времени (вспоминаем, с чего началась статья) очень плохо выражается в классической логике предикатов и высшие порядки тут не спасают. Это осознано давным давно и для задач, где требуется формализация понятия о времени, используют совсем другие формализмы. Смотрите, например, модели Крипке и конструктивные логики. Но, опять же, понять их можно, только хорошо понимая классическую логику.
                  Иногда время формализуют и в классической логике, для некоторых задач это возможно, но интервальная формализация, пожалуй, худшая из возможных, т.к. я не могу придумать ни одной разумной задачи, где бы такая формализация была продуктивной.

                  • mayorovp
                    /#10727176

                    А что не так со временем в логике?

                    • evkochurov
                      /#10727230 / +1

                      Тем, что классическая логика хорошо подходит только для описания положения дел в статике. Например, «эта машина — красная» (Цвет(Красный, Машина), тут я намеренно упрощаю, автор берет примеры, где аргументами являются не конкретные объекты, а множества) хорошо формулируется, если подразумевается конкретный момент времени. Если хочется в пределах одной теории говорить о разных моментах времени, то внезапно оказывается, что утверждение, истинное вчера, становится ложным сегодня. И приходится придумывать костыли, например, во все предикаты добавить дополнительный аргумент Т (Цвет(Красный, Машина, 27.03.2018) или, как у автора — не момент времени, а интервал).
                      А это, в свою очередь, приводит к куче трудностей: множество, которому принадлежит Т — оно какую мощность имеет? Как эти элементы соотносятся между собой? Как описать «поведение» предикатов и функций с течением времени, если оно имеет какие-то известные закономерности?

                      Т.е. не то чтобы на эти вопросы нельзя ответить, просто универсального ответа нет, и формализация времени, если уж уж в качестве формализма взята классическая логика, всегда делается под конкретную задачу.

                      Насколько я могу понять, автор и пытается с этими трудностями разобраться. Но как-то не с того конца…

                      • mayorovp
                        /#10727266

                        Время — это лишь еще одна координата. Усложнение предикатов — это, конечно, плохо — но но задача-то от добавления времени неразрешимой не становится!

                        • evkochurov
                          /#10727306

                          Время, как дополнительная координата — это только один из вариантов. Есть задачи, где время надо понимать сложнее. Например, если нам требуется выразить, что с течением времени наши знания растут (т.е. мы допускаем незнание об истинности некоторых утверждений, но однажды обретенное знание — не меняется и не теряется) и мы хотим понять, какими эти знания могут стать (или могли быть), а какими — нет. Вот тут и появляются модели Крипке.
                          А про неразрешимость я вроде бы ничего не говорил, только про зависимость решения от задачи.

                          • mayorovp
                            /#10727378

                            Не уверен что тут сложнее, а что проще — но как только в задаче появляется явная отметка времени (дата, номер года, день недели) — становится на одну координату больше.

                            Как программист я бы вовсе не рассматривал модели Крипке как что-то связанное со временем.

                            • evkochurov
                              /#10727460

                              Да, слишком замороченный пример я выбрал. Вот другой, более программистский: assert'ы — утверждения, которые должны быть истинны в заданных точках выполнения программы. Часто эти утверждения зависят от истории вычислений. Например, мы хотим сказать, что между точкой А и точкой Б должно пройти не больше X мс. Тут нас не интересует дата-время, а только длительность интервала времени от А до Б. Это тоже формализация понятия о времени, но другая. Все, что я хотел сказать: универсальной формализации нет, она всегда зависит от задачи, когда попроще, когда посложнее.

                              • mayorovp
                                /#10727466

                                Не вижу фундаментальных проблем, тут точно такая же ось времени выходит: f(..., Ta) & f(..., Tb) -> Tb — Ta < X

                                • evkochurov
                                  /#10727930

                                  Не понял, какой смысл несет предикат f? Для assert'а же достаточно простого Tb — Ta < X. Или даже Tab < X, если в программе уже имеется вычисленная длительность интервала.

  6. maxstroy
    /#10726516 / -2

    Если мы определим состояние объекта, как промежуток времени, в течение которого объект сохраняет какое-то свойство, то надо уточнить, что имеется ввиду не промежуток времени, а множество всех интервалов, которые можно получить из указанного промежутка. Равносильной альтернативой этому утверждению было бы следующее: в любой момент из указанного промежутка времени объект имел одно и то же состояние. Почему я не люблю вторую трактовку данного тезиса? Потому что она опирается на понятие мгновения, которое неизбежно приводит нас к понятию континуума. Моя трактовка опирается на здравый смысл и не требует понятия континуума.

    • mayorovp
      /#10726548

      Вот, о чем я и говорил: у вас появилось свое определение слова «состояние»… Состояние определенно не является промежутком времени.

    • akryukov
      /#10726554 / +1

      Чтобы описать интервал, вам точно так же нужен момент начала интервала и момент конца интервала. Ну или момент начала интервала и его длительность. В любом случае момент начала должен присутствовать. Поэтому вам все равно придется вводить понятие мгновения, которое, по вашим соображениям, требует понятия континуума.

    • michael_vostrikov
      /#10726592

      Потому что она опирается на понятие мгновения

      Она опирается на понятие шага дискретизации. Мгновением считается промежуток в пределах этого шага. То есть, приведенное утверждение равносильно тому, что насколько бы частей мы не поделили исходный промежуток, состояние объекта в пределах любой из них будет таким же. Как видите, никакого континуума не требуется.

      • maxstroy
        /#10726918 / -1

        Это в вашем воображении, а в воображении соседа — дискретизация иная.

        • michael_vostrikov
          /#10726950

          Ну и что? Состояние-то все равно такое же. Хотя вообще-то дискретизация задается единицами измерения и их взаимосвязями между собой.
          И да, чтобы все соседи понимали одинаково, существуют стандарты.

  7. Sinatr
    /#10726850 / +1

    Программирование — это процесс написания алгоритма. Алгоритм — это «упрощенная» логика, решающая определенную задачу в определенных условиях. Не пойму, каким образом специализированный обьект Interval, способный хранить 2 даты и сравнивать себя с другими обьектами (включая другие типы, например Date) вдруг становится вселенской нерешаемой проблемой, с континуумом, веществом и т.д.

    Вы, скорее всего, решаете какую-то определенную задачу, и потому вам, возможно, потребуется другой обьект, не Interval. Но я так и не смог понять, для решения какой задачи нужно зачему-то разбивать интервал на континуумы и хранить их.

    И не хватает выводов, что с того, что Interval такой, а не другой (который вам нужен)? Чем такое моделирование плохо?

    • maxstroy
      /#10726892

      Мы моделируем как можем. В ООП просто нет возможности моделировать множества средствами ООП. Моделирование множеств отдается на откуп программиста. При этом кто-то заявляет, что ООП предназначено для моделирования предметных областей. Именно этот тезис является ложным.

  8. Zenitchik
    /#10726944 / +1

    В ООП просто нет возможности моделировать множества средствами ООП.

    Моделирование множеств отдается на откуп программиста.

    Взаимоисключающие параграфы.

    • maxstroy
      /#10727178 / -1

      Я бы сказал так: нет штатных методов моделирования множеств. Если есть, сообщите. Если я хочу сообщить, что 70 процентов элементов множества обладают свойством ИКС, то как мне это сделать штатными способами?

      • lair
        /#10727186

        Я бы сказал так: нет штатных методов моделирования множеств.

        Есть. В ООП все есть объект, следовательно, штатный метод моделирования множества в ООП — моделирование его как объекта.


        Если я хочу сообщить, что 70 процентов элементов множества обладают свойством ИКС

        Что значит "сообщить"? Кому? В какой момент?

  9. KodyWiremane
    /#10727804

    Правильно ли я понял постановку проблемы в примере со станком: «Как в рамках ООП реализовать хранилище истории состояний объекта (станка) за некоторый интервал времени, с возможностью извлечь из этого хранилища состояние объекта, имеемое им в произвольно заданный с некоторой точностью (например, в сутках) интервал времени?»

    • maxstroy
      /#10727834 / -1

      Это пример такой задачи, но задача стоит иная. Нужен штатный механизм языка моделирования, который позволит сказать следующее: вот множество объектов, каждый объект данного множества обладает такими свойствами, 30 процентов — такими, 70 процентов — такими. Далее при работе с этим множеством мы берем любой его элемент и система автоматом предлагает нам выбрать свойств из перечисленных выше в порядке приоритета. Если мы не можем этого сделать, она приписывает объекту вероятность быть в таком состоянии или в таком до выяснения обстоятельств. Это есть моделирование в предикатах второго порядка, это крайне необходимо для моделирования, и это сильно меняет парадигму моделирования. С этого момента такие слова, которые нам принес ООП, как «экземпляр этого процесса» исчезнут, а вместо них появятся высказывания на русском языке.

      • Zenitchik
        /#10727894

        Нужен штатный механизм языка моделирования

        Кому нужен?

      • michael_vostrikov
        /#10727918

        такие слова, которые нам принес ООП, как «экземпляр этого процесса»
        Если вы не понимаете, что означает слово экземпляр, это не значит, что это слово неправильное, и уж тем более что оно должно исчезнуть по вашему желанию.

        Вы же сами пишете:
        habrahabr.ru/post/343316
        Поэтому одно скакание не есть то же скакание, но похожее.

        Скакание это процесс?

        • maxstroy
          /#10727926

          Извините, я писал об этом много и подробно. Почему нельзя говорить экземпляр этого процесса, — я объяснял неоднократно.

          • michael_vostrikov
            /#10728152

            Как странно. Вас не смущает, что вам неоднократно объясняли, что так обычно и не говорят? Что означает более употребляемая фраза «экземпляр процесса такого-то» и что означает более общая фраза «экземпляр типа» вам тоже объясняли неоднократно. Но вы, несмотря на неоднократность, почему-то эти объяснения игнорируете. Мало того, еще и указываете другим, какие термины должны быть в незнакомой вам предметной области, не разобравшись в значении этих терминов.

            Раз уж вы применили некрасивый прием ведения дискуссии «уход от ответа», я напомню вам сам.

            Вы писали:

            Инструкция — это типовой сценарий (модель процессов, типовой процесс, регламент), последовательность ваших действий — это сценарий, процесс.

            Типовой сценарий — это тип. «Обычный» сценарий — это экземпляр. Что тут сложного?

            Возвращаясь к вопросу. «Одно скакание» и «другое скакание» — это экземпляры. То, что означает термин «скакание» — это тип. От того, что вы их для себя называете другими словами, значение терминов в другой предметной области не поменяется.

            • maxstroy
              /#10728212 / -3

              Не надо говорить экземпляр процесса «принять заказ», а надо — процесс «принять заказ». Как только от ООПешников я услышу правильные термины, я успокоюсь и пойму, что они понимают, что освободились от своих заблуждений. А пока, извините, не вижу.

              • lair
                /#10728252 / +1

                Правильность термина может быть определена только в рамках системы терминов.

              • michael_vostrikov
                /#10728388 / +1

                Не надо говорить экземпляр процесса «принять заказ», а надо — процесс «принять заказ»

                Почему это? Почему вы считаете, что ваши термины правильные, а другие нет?


                А по-английски называть тоже никому нельзя, раз лично вы говорите по-русски? При этом ведь тоже другие слова используются. Это не риторический вопрос, ответьте пожалуйста, в чем вы видите разницу.


                Хорошо, допустим, некто сказал фразу 'процесс «принять заказ»'. Как понять, он имеет в виду типовой процесс, или нетиповой?

  10. KodyWiremane
    /#10727884

    * пардон, промахнулся мимо ветки *

    К сожалению, на сегодняшний день, словосочетание «предикат второго порядка» для меня звучит как «абра-кадабра», но для «Примера со станком» я, по крайней мере, в общих чертах могу представить реализацию. Можно попросить сформулировать задачу про множество объектов и 30% и 70% процентов в виде практического примера, «в станках»? Например:

    «На текущий момент в бизнес-центре в 100 офисах 100 принтеров: 30 принтеров марки Canine, 70 принтеров марки Epsilon; переходим к формированию поофисного списка…» Оно?

    • maxstroy
      /#10727956

      В лесу растут березы и елки. Лесоруб пошел в лес и завалил дерево. Какое дерево он завалил? Либо березу, либо елку. Так и запишем до выяснения обстоятельств. Или более практический пример, который встречается на каждом шагу, но почему-то не замечается. Пусть есть диаграмма в нотации BPMN. Там есть две «дорожки». одна с названием ИС, а вторая помечена как «менегер». С ИС все просто — вот она, а вот где менегер, если менегеров в офисе семь штук? Все дело в том, что дорожки выглядят одинаково, а вот смысл у них разный. У первой дорожки смысл: исполнитель — конкретная ИС, а у второй дорожки смысл иной: исполнитель — какой-то менегер из отдела. Согласитесь, это совсем не одно и то же. Вопрос: какой именно менегер будет делать работу? Какой-то, любой. Это утверждение относительно множества менегеров, а не относительно менегера. Понятно что моделировать утверждения относительно объектов не то же, что моделирование относительно множеств. К сожалению, об этом забывают.

      • KodyWiremane
        /#10727994

        Информация о рубке содержит Информация о срубленном дереве в нужном количестве; Информация о срубленном дереве содержит поле Порода дерева, которое может принимать одно из значений «Ель», «Берёза», «Не уточнено». Информацию касательно процентного соотношения можно получить через Информация о рубке, например. Зависит от того, откуда оно взялось: то ли задание нарубить было в процентах, то ли в лесу столько растёт… То же с менегерами. Информация об исполнителе содержит поле Отдел исполнителя, булево поле Назначен конкретный исполнитель, поле Конкретный исполнитель с типом данных, обозначающим сотрудника. Либо без буля, с магическим объектом сотрудника «Любой сотрудник».

        • maxstroy
          /#10728148 / -1

          Вы говорите о программировании в ООП, я же говорю о том, что ООП, декларируя одно, реализует совсем иное. Например, когда мне надо смоделировать менегера, ООП называет его экземпляром этого менегера, когда мне надо смоделировать класс менегеров, у меня нет штатного механизма, когда мне надо смоделировать тип менегеров, ООП называет его менегером. Когда мне надо смоделировать операции на множестве, ООП молчит. Я не понимаю, как в такой каше вообще возможно какое-то моделирование. Именно это я пытаюсь объяснить. ООП не моделирует предметные области, но хорошо подходит для программирования. Главное — не тащить термины ООПв предметную область, чего так любят делать.

          • lair
            /#10728260 / +1

            Например, когда мне надо смоделировать менегера, ООП называет его экземпляром этого менегера, когда мне надо смоделировать класс менегеров, у меня нет штатного механизма, когда мне надо смоделировать тип менегеров, ООП называет его менегером.

            Нет и еще раз нет. Слушайте, уже сколько раз вам говорили: вы просто не понимаете, как работает ООП, зачем вы в него лезете? Вы же не программист, в конце концов, занимайтесь своим моделированием спокойно.


            ООП не моделирует предметные области, но хорошо подходит для программирования.

            Главное, не забывать, что в процессе программирования может возникать модель предметной области (и чаще всего возникает).


            Главное — не тащить термины ООПв предметную область, чего так любят делать.

            Кто любит-то? Я, например, неоднократно говорил вам, что тащить термины из любой имплементации, не важно, ООП это или БД (или теория типов, или машинное обучение, или что угодно еще) в предметную область — неправильно, и этого надо избегать.

          • mayorovp
            /#10728286

            когда мне надо смоделировать класс менегеров, у меня нет штатного механизма

            Откуда взялось понятие "класс менегеров" в предметной области? Кажется, вы сами только что зачем-то вытащили технический термин в предметную область.


            И то же самое по поводу "типа менегера" — в предметной области его тоже не существует. Либо существует, но означает что-то совсем иное, и ООП точно не называет его менегером.

          • KodyWiremane
            /#10729216

            Да, я заглянул в историю публикаций, теперь понимаю так, что вопрос не о возможности реализации «по ООП», а о терминологии. Не являясь гуру программирования, я уточню определения с помощью Википедии:

            Объе?кт в программировании — некоторая сущность в компьютерном пространстве, обладающая определённым состоянием и поведением, имеющая заданные значения свойств (атрибутов) и операций над ними (методов).
            (Объект (программирование))
            Класс — это элемент ПО, описывающий абстрактный тип данных и его частичную или полную реализацию.
            Практически класс может пониматься как некий шаблон, по которому создаются объекты — экземпляры данного класса. Все экземпляры одного класса созданы по одному шаблону, поэтому имеют один и тот же набор полей и методов.
            В объектно-ориентированной программе с применением классов каждый объект является «экземпляром» некоторого конкретного класса, и других объектов не предусмотрено. То есть «экземпляр класса» в данном случае означает не «пример некоторого класса» или «отдельно взятый класс», а «объект, типом которого является какой-то класс».
            (Класс (программирование))

            Т. е. Manager manager1 = new Manager(); создаёт экземпляр ООП-класса Manager, т. е. создаёт некую численно описывающую менегера структуру в соответствии с шаблоном Manager. Поскольку ООП-классы не являются необходимым компонентом ООП, можно достичь аналогичного эффекта через Object manager1 = createManager();. Т. е. «экземпляр процесса» — не более чем фигура речи, сленг. Вас, как я понимаю, больше интересовал не ООП-класс (шаблон создания информационной структуры), а класс как множество объектов, имеющих некоторый признак(и), или как набор самих признаков, по которым объект может быть отнесён к этому классу. Так ли это?

            Насчёт множеств, насколько я знаю, примитивный тип данных set — это фактически сахар для битовой карты. Т. е. речь идёт о фиксированном наборе идентификаторов, для каждого из которых хранится информация, присутсствует ли он в этом «множестве» или нет. Если говорить о множестве как о динамически определяемой совокупности объектов… ООП позволяет создавать объекты, трактовкой же их занимается программист, поэтому ничто не мешает создать объект, моделирующий множество: содержащий список членов множества, операции добавления, удаления членов и проверки вхождения значения в множество, пересечения и т. д.

            В конце концов, можно создать язык программирования (или диалект), соответствующий вашим терминологическим потребностям. Фреймворк, наконец. А, может, он уже есть.

            • maxstroy
              /#10729626

              Вы говорите абсолютно верные вещи. Я могу создать любой нужный фреймворк с терминами, которые приняты в сообществе математиков, где класс — это а-ля множество, а то, что названо классом в ООП, назову типом. Я могу создать все, что угодно, но почему я против того, чтобы гуру ООП говорили о возможности моделирования при помощи ООП? Потому что из-за скошенных терминов в предметные области стали проникать термины, которые не переводятся на русский язык, например, экземпляр этого процесса. Я не знаю, насколько надо не любить ни логику, ни язык, чтобы так говорить, но программист не замечает всей дикости этого высказывания! И от этого возникают такие искажения в мозгу, которые уже не лечатся. Посмотрите выше и вы поймете, что программисты реально думают, что такой термин допустим в русском языке и имеет какой-то смысл! Причина — в ООП!

              • michael_vostrikov
                /#10729666 / +2

                термины, которые не переводятся на русский язык, например, экземпляр этого процесса
                программисты реально думают, что такой термин допустим в русском языке

                Ну сколько можно говорить. Такое словосочетание может иметь смысл в некотором контексте. Это не является общепринятым термином, это отсылка к нему в редуцированном виде. Правильный термин другой. Почему вы продолжаете высказывать заведомо неверные утверждения?


                Я не знаю, насколько надо не любить ни логику, ни язык

                Комменты и выше и в других статьях написаны русским языком. Насколько надо не любить ни логику, ни язык, чтобы не понимать одних и тех же доводов, повторенных много раз?


                Вы высказываете необоснованные утверждения и уходите от ответа, когда спрашивают о причинах или приводят противоречащие этому примеры.
                Вы задаете вопросы, и получив ответы, продолжаете задавать их же в дальнейшем, хотя не приводите контр-аргументов, почему ответ вам не подходит.
                Вы даже не смогли сформулировать ответ на вопрос, в чем вы видите различия между другими названиями на одном языке и названиями на другом языке.
                Что там про логику и владение языком?

              • lair
                /#10729898

                Потому что из-за скошенных терминов в предметные области стали проникать термины

                Нет, термины в предметные области стали проникать из-за недостаточной аккуратности в процессе разработки.


                Вы думаете, термины "таблица БД" и "запись БД" в бизнес-требованиях чем-то лучше "класса"?


                Посмотрите выше и вы поймете, что программисты реально думают, что такой термин допустим в русском языке и имеет какой-то смысл!

                В русском языке допустим любой "термин", потому что в языке терминов нет, они есть только в предметной области.

                • maxstroy
                  /#10730574 / -1

                  Никто не говорит процесс «принять заявку», вместо этого — экземпляр процесса «принять заявку» Вы разницу видите?! Я вижу. А вместо того, чтобы сказать тип процессов вы говорите процесс! Разница есть?

                  • Zenitchik
                    /#10730792

                    Строго говоря, Вы правы. Но от сокращения смысл не страдает. Дураку же ясно, что подразумевается тип процесса, а короче на два слога — т.е. вдвое.

                  • lair
                    /#10730878

                    Вы разницу видите?

                    Разницу между чем и чем? Из вашего комментария даже не понятно, кто как говорит, и как по-вашему надо.


                    вместо того, чтобы сказать тип процессов вы говорите процесс

                    Я? Нет, я так не говорю.

            • maxstroy
              /#10729678 / -1

              Собственно, ответ ниже подтверждает мои слова о том, что адепт ООП не понимает коллизий в своих высказываниях. Когда я спрашиваю, чем экземпляр процесса отличается от процесса, мне говорят, что ничем. Я спрашиваю: по логике это значит, что можно заменить термин экземпляр этого процесса на процесс. Но мне отвечают, что в ООП это сделать нельзя. И это все наравне с якобы пониманием коллизии. Противоречие самому себе — это круто! Иногда мне говорят, что экземпляр процесса — это воплощение процесса. Это другая история — под процессом начинают понимать тип процессов. Это еще одна проблема адепт ООП не различает объект и тип объектов. Или различает, но тип называет именем объекта, а объект — именем объекта с приставкой экземпляр этого. При этом заменить термины нельзя, потому что это ООП, детка.

              • michael_vostrikov
                /#10729742 / +1

                чем экземпляр процесса отличается от процесса, мне говорят, что ничем

                Вам говорят, что то, что вы называете "просто процесс", в другой системе терминов называется "экземпляр типа 'Процесс'".


                Я спрашиваю: по логике это значит, что можно заменить термин экземпляр этого процесса на процесс.

                Нет, вы не говорили о замене одного правильного термина на другой. Вы говорили, что термин "экземпляр" неправильный. Спорят с вами по поводу правильности, а не по поводу замены.


                Кстати, почему вы продолжаете употреблять выражение "экземпляр этого процесса", если вам сказали, что в отрыве от контекста оно не употребляется? Правильная форма — "экземпляр типа 'Процесс'" или "экземпляр этого типа", в крайнем случае "экземпляр процесса '<более конкретное название типа процессов>'". Если вы собираетесь снова обсуждать это в дальнейших статьях, используйте одну из этих форм, чтобы быть понятым другими.


                Но мне отвечают, что в ООП это сделать нельзя.

                Не могли бы вы привести ссылку, где именно вам такое сказали?
                Вам говорили о том, что термин "экземпляр" корректен, и что отказ от него будет вызывать неоднозначность в выражениях вида 'процесс «принять заказ»'. На вопрос, как устранить неоднозначность в вашей системе терминов, вы тоже ответить не смогли.


                но тип называет именем объекта, а объект — именем объекта с приставкой экземпляр этого

                Вы пишете:
                "Поверхность – это проекция 4-Д объема на пространство в виде поверхности, ограничивающей объем."


                Здесь вы явно говорите не о конкретной поверхности, следовательно, о типовой.
                Почему вы типовое понятие называете именем объекта (а именно словом "поверхность"), если считаете, что это неправильно?


                И нет, тип называют именем с приставкой "тип", а объект именем с приставкой "экземпляр". Если это не ясно из контекста, либо если ясно, но нужно сослаться на другой смысл.


                P.S. Если у вас есть возражения, не могли бы вы высказывать их прямо, а не косвенно через комментарий другого человека. Это к вопросу о вашей логике.

      • lair
        /#10728002

        Это утверждение относительно множества менегеров, а не относительно менегера

        А вот кстати нет. Это утверждение относительно неизвестного на данный момент объекта, удовлетворяющего некоему критерию (в данном случае — "менеджер из отдела").


        Ну и как бы все равно не понятно, какую задачу вы решаете.