Pull to refresh

Comments 11

Нельзя ли поподробнее раскрыть тему про свой компилятор PL/I?
компилятор называется PL/1-KT, легко найти сайт, где он есть с описанием
Очень интересно, буду изучать. Компилятор DR я помню, в своё время он на меня особого впечатления не произвёл (я видел порт из CP/M в MS-DOS 1.0 с соответствующими ограничениями вроде незнания о каталогах).
UFO just landed and posted this here
> Как пример важности таких проверок корректности можно привести неудачу миссии Mars Climate Orbiter 23 сентября 1999 года из-за расчетов в «не тех» единицах измерения. Вполне вероятно, что если бы используемые трансляторы тогда имели бы механизм «физических» типов, подобный приведенному выше, а также автоматический вывод в системных единицах, можно было бы выполнять расчеты в злополучных «фунт-силах», но при этом избежать последующих разночтений с печальными последствиями.

Одна из причин, почему в C++ ввели user-defined literals: www.stroustrup.com/C++11FAQ.html#UD-literals, теперь в плюсах тоже можно указывать единицы измерения у значений.
С масштабными коэффициентами не очень красиво получилось, они вводятся не только для удобства, но и для получения более точного результата. То есть, если вы оперируете ГигаГерцами, то и точности нужны относительно миллиардов Герц, если оперируете наносекундами, то точности относительно миллионнных долей секунды. Постоянное же приведение к базовым величинам, как раз выдёргивает размерности не в свой диапазон, в результате числовые значения могут стать погрешностями и отсекаться в вычислениях.

P.S. Что-то такое было с ракетой: считалось количество секунд с момента старта сверхмалыми приращениями и как только сумма стала достаточно большой (в базовых величинах) то приращения вышли за минимальный диапазон и стали округляться до нуля, поэтому счёт времени остановился.
К сожаление, из статьи «выпал» рис. 3, как раз показывающий работу проверок типов
image
При сравнении «физические» типы оказались несравнимы

А откуда взялся пример про разные типы для длинны и ширины?

Для класса «инженерных» задач эта идея – использовать как систему типов Международную систему единиц СИ, всегда казалась мне очевидной и потенциально полезной, но почему-то нигде в современных распространенных языках не реализованной, за исключением некоторых возможностей в Matlab и Mathcad.

Ну так-то есть библиотеки для C++, для Python, для Julia.

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

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

На самом деле это совсем не так. Например, возьмем денежные операции. Я не могу Вам дать меньше одной копейки в физическом мире. И взять не могу меньше одной копейки. Конечно, валюты со временем меняются. И в конечном счете - сейчас уже фактически расчеты меньше, чем в рублях (опять же в физическом мире) не имеют смысла. Но здесь я иллюстрирую, что у любого физического типа есть некий минимальный квант. например, для расстояния это будет расстояние планка. Для заряда - я так понимаю - заряд электрона (не может быть дробного заряда). И так далее. То есть ДЕ ФАКТ у нас величины все являются не значениями с плавающей точкой, а скорее bigint в диапазоне возможных изменений, которые мы можем наблюдать в природе. Опять же - мы можем попасть в беду, если будут установлены какие-то новые физические законы. Или мы захотим (как с финансами) считать сложные проценты с накоплением частей минимальной единицы... Но в принципе - почему было бы не попробовать?

С другой стороны, такой подход возможно был бы контрпродутивным, потому что мы все-таки живем в реальном мире и переопределять эти недискретные величины в виде меры количества... ну такое... Сегодня линейка была "5 тера"расстояний планка, а завтра 5T+1 - не очень практично, проще говорить, что она 5 метров...

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

а еще проценты % и промилле ‰, ага. С градусами такая же история (если мы говорим про углы) - мы запросто могли бы их считать в количествах Pi, то есть в физическом мире нет градусов на самом деле. И точно так же как и с процентами и промилле - мы вынуждены градусы переводить в безразмерную единицу (радиан). А наличие sin/sind вызовов в конкретном ЯП - это всего лишь артефакт языка, а не реально отражение системы типов (как будто бы). Потому что иначе надо идти дальше и вводить проценты как отдельный подтип... Чтобы можно было делать операции с безразмерными величинами и процентами...

Или мы захотим (как с финансами) считать сложные проценты с накоплением частей минимальной единицы...

Область финансовых расчетов - "это другое". Там давным-давно предложен другой способ

Sign up to leave a comment.

Articles