Как стать автором
Обновить

Реальность существует и это надо учитывать

Время на прочтение11 мин
Количество просмотров27K

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

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

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

  • историки рассказывают "это произошло потому, что"

  • айтишники же говорят "мы сделали цифровой двойник предприятия" или "мы используем данные о производстве для машинного обучения"

Проблема в том, что мы (и айтишники и историки) сперва задаём сами себе вопрос "Какой вывод мы можем сделать на основании этих данных?". Ну а вопрос "Как мы можем проверить эти данные?" мы либо не задаём вообще, либо откладываем на потом и, в конечном счёте, не задаём вообще.

Реальность существует и это надо учитывать
Реальность существует и это надо учитывать

Разница между айтишниками и историками

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

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

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

Если кто-то скажет нам, что мы не можем сделать расчёт исходя из имеющихся данных, то мы не поймём. Вот данные, вот арифметческие операции - конечно же можем!

У историков другая проблема: они игнорируют реальность потому, что они бессильны - у них нет машины времени. У историка есть только "источник" и он его "трактует".

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

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

Просто потому, что иного выбора у нас нет - мы либо принимаем написанно в источнике как исторический факт, либо лишаемся возможности работать.

Так мы можем или нет?

На самом деле, ситуация не настолько однозначная, как я написал выше.

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

Когда айтишники создают цифровой двойник аппарата или предприятия они собирают ретроспективные данные и тоже проверяют их на странности.

Но как именно мы (историки и айтишники) проверяем имеющиеся у нас данные? Скорее всего, мы находим наиболее вероятные "минимум" и "максимум", а всё что не попало а этот диапазон отбрасывается как ошибочное.

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

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

Потому, что эти цифры должны отражать реальность.

Реальность конечна

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

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

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

Да, вы правы, я просто применил инженерные расчёты к ретроспективным историческим данным и недостоверные данные стали проявляться сами собой. Отраслевые журналы 1930-х, техническая литература 1960-х, веб-сайты, содержащие подборку информации о разных видах техники - везде были ошибки в данных.

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

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

Для этого потребовалось всего лишь сказать себе "это не просто ретроспективные данные, а цифровой двойник автомобиля/мотоцикла/самолёта/бензопилы".

Почему этого никто не делает

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

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

Как-то я увидел в медицинском журнале статью, о том, как решалась задача сведения воедино разношёрстных данных, полученных из разных источников и содержащие данные в разных единицах измерения.

Я стал читать эту статью, в расчёте увидеть, как на практике решают интересующую меня проблему.

Там был рассказ о том:

  • какие бывают онтологии и варианты описания данных

  • какие сервисы позволяют работать с этими данными и преобразовывать одну размерность в другую

  • как всё это собрать в свой собственный сервис

  • было сказано, что описанный вариант требует повышенных вычислительных ресурсов и сколько времени конкретный пример обрабатывался на компьютере авторов

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

Но я искал там другое, мне хотелось узнать, что именно они делали с данными, у которых не было указания размерности.

У них были данные в СИ, были данные в имперских единицах и были данные без размерности, а значит они должны были как-то обосновать выбор единиц измерения для данных без размерностей. Ведь должны же, правда?

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

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

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

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

Так что делать?

Так как речь идёт о массовой профессии, то самым очевидным вариантом является продвижения правильного подхода, правильной модели поведения.

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

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

Да, вы правильно поняли, я веду речь о создании соответствующего "принципа программирования".

Конечно же, я знаю, их и так много [1][2][3][4], но они посвящены тому как писать код, который скомпилится без ошибок, и не затрагивают вопрос о том, будет ли при этом получен результат имеющий физический смысл.

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

В качестве названия этой парадигмы я выбрал рекурсивный акроним UNITS (Units Not more Important Than Smysl), акцентируя внимание на том, что речь не просто о единицах измерения, но именно о физическом смысле.

Так же стоит отметить, что в качестве примеров я буду не только рассказывать примеры из своего опыта, но и ссылаться на статьи Валерия Фёдоровича Очкова [5]. Это профессор МЭИ, доктор технических наук и автор книг, с которых кто-нибудь из здесь присутствующих мог начинать своё "войти в IT".

Последние несколько лет он активно пишет на тему использования именованных величин и физического смысла, при проведении расчётов в SMath и MathCad. Дальнейший текст является результатом объединения моего собственного опыта и примеров из его статей.

Другой причиной ссылаться на статьи Очкова является то, что, в отличии от меня, он свои статьи писал, а я просто взял в 2020 году домен с мыслью "когда-нибудь запилю тематический проект, понапишу статей и выложу в интернет", и все эти годы просто продолжаю сам для себя играться датасетами.

Манифест парадигмы UNITS

UNITS это рекурсивный акроним "Units Not more Important Than Smysl" - означающий, что единицы измерения не важнее смысла расчёта.

При создании цифровых двойников и в машинном обучении, надо учитывать не только формат записи чисел и статистическую достоверность данных, но и их физический смысл.

Следование парадигме UNITS позволит не только корректно подготовить ретроспективные данные, но и правильно собирать и хранить данные о текущем функционировании промышленных объектов, для их дальнейшего использования в цифровых двойниках и при машинном обучении.

Сама парадигмы UNITS состоит из 5 положений, по числу букв:

  1. У величин должны быть свойства, указывающие на их физический смысл

  2. У величин должна быть размерность, соответствующая их физическому смыслу

  3. Свойства и размерности величин должны соответствовать физическому смыслу проводимого расчёта

  4. Числовое значение величин должно соответствовать их физическому смыслу в контексте выполняемого расчёта

  5. У оператора должна быть возможность проигнорировать любые несовпадения и сознательно выполнить расчёт, не имеющий физического смысла

В чём смысл каждого из них:

1. У величин должны быть свойства, указывающие на их физический смысл

Этот вопрос прорабатывается уже давно и плотно = нас уже есть OWL , RDF и другие решения для онтологий.

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

Например, в теплотехнических расчётах, можно ошибочно попытаться выполнить операции над величинами обозначающими свойства разных теплоносителей. [6 , с.8]

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

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

2. У величин должна быть размерность, соответствующая их физическому смыслу

Не смотря на большое количество библиотек [7], работающих с размерностями, и наличие этого функционала в программах SMath , MathCad и др., современные решения имеют существенный недостаток - сокращение размерности.

Например, "трёхэтажная" размерность вязкости сокращается до Па*с (единицы измерения давления, Паскаль) [8 , с.43], что не отражает физического смысла вязкости.

И хотя сокращение размерностей является частью ГОСТ-8.417-2002 ( см. пункт 5.2.6 ) [9] , оно не является настолько уж полезным.

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

3. Свойства и размерности величин должны соответствовать физическому смыслу проводимого расчёта

В настоящий момент мы имеем 7 основных единиц СИ, из которых можно скомбинировать производные единицы.

Если подходить с позиции "можно технически", то из исходных 7 единиц можно создать бесконечное количество производных комбинаций. Однако, если помнить о физическом смысле, то количество производных величин уменьшится до нескольких десятков, а при проведении конкретного расчёта по конкретной теме, количество реально используемых единиц становится совсем небольшим.

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

4. Числовое значение величин должно соответствовать их физическому смыслу в контексте выполняемого расчёта

В общем случае у нас есть минимальные и максимальные значения некоторых физических величин.

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

В конкретных физических расчётах могут быть дополнительные граничные значения, например, температура пара в турбине врядли превысит 1000 градусов Цельсия. Причём, эти значения могут быть заданы не просто для темы расчёта, но и для конкретных вычислений и формул. [10 , с.4] [11 , с.7 ]

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

5. У оператора должна быть возможность проигнорировать любые несовпадения и сознательно выполнить расчёт не имеющий физического смысла

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

Это может быть простой математический расчёт где X складывается с квадратом самого себя (что не имеет физического смысла).

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

Мы не знаем, что и зачем рассчитывает человек, но у него должна быть возможность как включить автоматический контроль физического смысла расчёта, так и выключить его.

А это вообще возможно?

Да, если не пытаться создать универсальный фреймворк на все случаи жизни.

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

Михаил Елисейкин помнит о том, что бензопила это физический процесс и проверяет корректность исторических сведений.

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

Если вы создаёте цифровой двойник предприятия или готовите данные для машинного обучения, то просто помните о физическом смысле этих данных и физическом процессе их возникновения.

Это может помочь Вам проконтролировать правильность расчёта и сэкономить время на поиске ошибок.

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

Помнить о физическом смысле расчёта может иметь смысл.

2023-11-27 / Михаил Елисейкин

Список источников

  1. "Категория:Принципы_программирования" , https://ru.wikipedia.org/wiki/Категория:Принципы_программирования , Википедия , дата обращения: 2023-11-27

  2. "Category:Programming_principles" , https://en.wikipedia.org/wiki/Category:Programming_principles , Википедия , дата обращения: 2023-11-27

  3. "Принципы для разработки: KISS, DRY, YAGNI, BDUF, SOLID, APO и бритва Оккама" , https://habr.com/ru/companies/itelma/articles/546372/ , автор: @Itelma , дата публикации: 2021-03-10 , дата обращения: 2023-11-27

  4. "10 важнейших принципов разработки программного обеспечения" , https://habr.com/ru/articles/589489/ , автор: @nikitaulshin , дата публикации: 2021-11-16 , дата обращения: 2023-11-27

  5. "Очков, Валерий Фёдорович" , https://ru.wikipedia.org/wiki/Очков,%D0%92%D0%B0%D0%BB%D0%B5%D1%80%D0%B8%D0%B9%D0%A4%D1%91%D0%B4%D0%BE%D1%80%D0%BE%D0%B2%D0%B8%D1%87 , Википедия , дата обращения: 2023-11-27

  6. В.Ф. Очков, К.А. Орлов, А. Даваахуу. Интеллектуальная компьютерная метрология // Законодательная и прикладная метрология. № 6, 2022 , http://twt.mpei.ac.ru/ochkov/Ochkov-PhysicValues.pdf

  7. "A Comprehensive List of Unit Checker Libraries" , https://github.com/OscarBennich/Comprehensive-List-Of-Unit-Checker-Libraries , автор: OscarBennich , дата обращения: 2023-11-27

  8. Очков В.Ф., Орлов К.А. Когда p v = T // Законодательная и прикладная метрология. № 2. 2022. С. 38-44 , http://twt.mpei.ac.ru/ochkov/2022_02-ZiPM.pdf

  9. "Межгосударственный стандарт ГОСТ 8.417-2002 "Государственная система обеспечения единства измерений. Единицы величин" (введен в действие постановлением Госстандарта РФ от 4 февраля 2003 г. N 38-ст)" , https://base.garant.ru/3924380/

  10. Очков В.Ф., Орлов К.А., Очков А.В., Ильина И.П. Теплотехнические расчеты с облачными функциями по свойствам воды и водяного пара // Электрические станции. № 7. 2015. C. 21-26 , http://twt.mpei.ac.ru/ochkov/Elect-Plants-CloudFunction.pdf

  11. Очков В.Ф. Облачный» сервис по свойствам рабочих тел и материалов атомной энергетики (pdf-макет) (по-английски) // Автоматизация и IT в энергетике, № 3, 2012, С. 4-8. , http://twt.mpei.ac.ru/TTHB/npp/CC.pdf

Теги:
Хабы:
Всего голосов 30: ↑21 и ↓9+12
Комментарии135

Публикации

Истории

Работа

Data Scientist
56 вакансий

Ближайшие события

Конференция «Я.Железо»
Дата18 мая
Время14:00 – 23:59
Место
МоскваОнлайн
Антиконференция X5 Future Night
Дата30 мая
Время11:00 – 23:00
Место
Онлайн
Конференция «IT IS CONF 2024»
Дата20 июня
Время09:00 – 19:00
Место
Екатеринбург