Оберон-клуб «ВЄДАsoft»

Твердыня модульных языков
Текущее время: 28 мар 2024, 23:15

Часовой пояс: UTC + 2 часа




Начать новую тему Ответить на тему  [ Сообщений: 30 ]  На страницу Пред.  1, 2, 3
Автор Сообщение
СообщениеДобавлено: 28 дек 2013, 16:33 
Не в сети

Сообщения: 203
igor писал(а):
geniepro писал(а):
А вот если по задаче нужны такие дополнительные ограничения, ...
... , то лучше их решать на уровне задачи, а не на уровне языка. ИМХО.

Пример? Вот хотя бы на задаче вычисления площади и периметра...


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 29 дек 2013, 09:38 
Не в сети

Сообщения: 13
Хочу немного пояснить что я сказал. "Решать на уровне задачи" в данном контексте означает "отдать на откуп программисту". С точки зрения программы все числа должны оставаться абстрактными, иначе придётся тащить в язык весь ГОСТ 8.417-81.
Пример решения с абстрактными числами, которые для программиста что-то там значат, приводить смысла нет, так как он банален.


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 29 дек 2013, 15:22 
Не в сети

Сообщения: 203
igor писал(а):
Хочу немного пояснить что я сказал. "Решать на уровне задачи" в данном контексте означает "отдать на откуп программисту". С точки зрения программы все числа должны оставаться абстрактными, иначе придётся тащить в язык весь ГОСТ 8.417-81.

Не понимаю, чему Вы противоречите.
В F#, где поддержка единиц измерений сделана на уровне языка, программисту даётся лишь возможность вводить свои единицы измерений, а компилятор затем проверяет согласованность их использования.
В Хаскелле единицы измерений SI, CGS, некоторые другие, сделаны в виде отдельной библиотеки, которую можно использовать, а можно не использовать.
Так в чём проблема-то?


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 29 дек 2013, 20:28 
Не в сети

Сообщения: 13
geniepro писал(а):
В F#, где поддержка единиц измерений сделана на уровне языка, программисту даётся лишь возможность вводить свои единицы измерений, а компилятор затем проверяет согласованность их использования.
В Хаскелле единицы измерений SI, CGS, некоторые другие, сделаны в виде отдельной библиотеки, которую можно использовать, а можно не использовать.
Так в чём проблема-то?
Допустим, Вы пишете программу, которая моделирует работу трансформатора, и решили ввести единицы измерения веберы [Вб] и амперы [А] для того чтобы не напороть косяков в вычислениях. Так вот, основная кривая намагничивания у Вас аппроксимируется полиномом седьмой степени. Но как только Вы попробуете воспользоваться этим полиномом для вычисления тока намагничивания по известному основному потокосцеплению, компилятор начнёт некстати "умничать". Причина в том, что аппроксимирующий полином - это эмпирическое соотношение, которое не несёт в себе никакого физического смысла. И такие ситуации возникают в нетривиальных задачах сплошь и рядом.

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


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 29 дек 2013, 21:22 
Не в сети

Сообщения: 203
igor писал(а):
geniepro писал(а):
В F#, где поддержка единиц измерений сделана на уровне языка, программисту даётся лишь возможность вводить свои единицы измерений, а компилятор затем проверяет согласованность их использования.
В Хаскелле единицы измерений SI, CGS, некоторые другие, сделаны в виде отдельной библиотеки, которую можно использовать, а можно не использовать.
Так в чём проблема-то?
Допустим, Вы пишете программу, которая моделирует работу трансформатора, и решили ввести единицы измерения веберы [Вб] и амперы [А] для того чтобы не напороть косяков в вычислениях. Так вот, основная кривая намагничивания у Вас аппроксимируется полиномом седьмой степени. Но как только Вы попробуете воспользоваться этим полиномом для вычисления тока намагничивания по известному основному потокосцеплению, компилятор начнёт некстати "умничать". Причина в том, что аппроксимирующий полином - это эмпирическое соотношение, которое не несёт в себе никакого физического смысла. И такие ситуации возникают в нетривиальных задачах сплошь и рядом.

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


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 30 дек 2013, 08:36 
Не в сети

Сообщения: 13
geniepro писал(а):
В таких случаях можно использовать явное приведение типов, ...
Да, можно. Но стоит ли овчинка выделки? Это вопрос для создателей языков и библиотек.
geniepro писал(а):
... , для того что бы внести физический смысл в такие эмпирические кривые.
Похоже, Вы так и не поняли о чём я тут толкую. Эмпирические соотношения по своей природе не несут никакого физического смысла, они лишь имитируют реальную физическую зависимость (с какой-то погрешностью). Единицы измерения им просто противопоказаны, правила размерностей не соблюдаются в принципе. И если кто-то тащит в язык единицы измерения, то должен также предусмотреть "лазейки" в языке для того, чтобы в нужный момент иметь возможность обойти систему типов. А это очень нехорошо для языка.


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 30 дек 2013, 11:53 
Не в сети

Сообщения: 203
igor писал(а):
geniepro писал(а):
... , для того что бы внести физический смысл в такие эмпирические кривые.
Похоже, Вы так и не поняли о чём я тут толкую. Эмпирические соотношения по своей природе не несут никакого физического смысла, они лишь имитируют реальную физическую зависимость (с какой-то погрешностью). Единицы измерения им просто противопоказаны, правила размерностей не соблюдаются в принципе. И если кто-то тащит в язык единицы измерения, то должен также предусмотреть "лазейки" в языке для того, чтобы в нужный момент иметь возможность обойти систему типов.
Да понял я, об этом и толкую.
Допустим, есть некая функция, аргументы которой имеют единицы измерений, и результат тоже должен иметь соответствующую единицу измерений. Однако зависимость между результатом и аргументами является эмпирической аппроксимацией. При расчёте этой зависимости лишаем аргументы единиц измерений явным приведением типов к вещественному типу, результат зависимости также явно приводим к нужному типу. Таким образом, при использовании этой функции мы имеем согласованные типы, с правильными единицами измерений.
Проблема решена, не так ли?

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


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 30 дек 2013, 19:57 
Не в сети

Сообщения: 203
Ленивый valexey с оберспейса предлагает другое решение этой проблемы, без явных и опасных приведений типов -- обезразмерить входные параметры, умножив метры на метры в минус первой степени и тд, а результат соответственно помножить на нужную единицу измерений.
В принципе, думаю, в том же F# что-то типа того и производится, когда тип float<m> приводится к типу float, например...


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 31 дек 2013, 14:10 
Не в сети

Сообщения: 13
geniepro писал(а):
Допустим, есть некая функция, аргументы которой имеют единицы измерений, и результат тоже должен иметь соответствующую единицу измерений. Однако зависимость между результатом и аргументами является эмпирической аппроксимацией. При расчёте этой зависимости лишаем аргументы единиц измерений явным приведением типов к вещественному типу, результат зависимости также явно приводим к нужному типу. Таким образом, при использовании этой функции мы имеем согласованные типы, с правильными единицами измерений.
Проблема решена, не так ли?
Да, конечно так можно.
Хочу здесь немного описать свой подход. У меня все числа в программе абстрактные, но при этом все физические величины выражены в единицах СИ. (Относительные единицы я тоже использую, но про это отдельный разговор). Допустим, если у меня где-то в вычислениях фигурируют десять микрофарад, то это значение у меня представлено как 10e-6, а не как 10. Далее, применяем правильную формулу из физики, и автоматически получаем правильные единицы на выходе. Правильность преобразования единиц измерения гарантируется самой формулой, и не требует дополнительной опеки со стороны компилятора. Конечно же, если Вам такая опека нужна, то никто не станет возражать против использования Вами соответствующих инструментов (F# и т.д.)

PS: Через 5 часов наступит Новый Год. Поздравляю всех с этим замечательным праздником! :)


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 31 дек 2013, 17:18 
Не в сети

Сообщения: 203
igor писал(а):
Правильность преобразования единиц измерения гарантируется самой формулой,
Кто даст гарантию, что формула реализована правильно?

igor писал(а):
и не требует дополнительной опеки со стороны компилятора. Конечно же, если Вам такая опека нужна, то никто не станет возражать против использования Вами соответствующих инструментов (F# и т.д.)
Если бы программисты не нуждались в опеке со стороны компилятора, то до сих пор, как настоящие мужики, писали бы программы в машинных кодах, битики тасовали бы.
Никто не застрахован от ошибки, и если компилятор может помочь обнаружить ошибку в программе на ранней стадии -- в процессе её написания -- то это лучше, чем если от него такой помощи не будет.


Вернуться к началу
 Профиль  
Ответить с цитатой  
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 30 ]  На страницу Пред.  1, 2, 3

Часовой пояс: UTC + 2 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 2


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
cron
Создано на основе phpBB® Forum Software © phpBB Group
© VEDAsoft Oberon Club