nabbla (nabbla1) wrote,
nabbla
nabbla1

Category:

Пожелания к PhysUnitCalc

Скоро калькулятору с физическими размерностями - PhysUnitCalc - исполнится год. Я сам им успешно пользуюсь на работе и в повседневной жизни, пытаюсь "подсадить" окружающих, и иногда это получается - электронщику нашему нафиг были не нужны размерности, но оператор || ("параллельное соединение", a||b = a*b/(a+b) ) оказался решающим аргументом.

Но всё-таки до сих пор программа сыровата, а хочется довести её до ума.

Мне понравилось создавать опросы, вот ещё один: что хотелось бы исправить и добавить в PhysUnitCalc конкретно вам? Под катом пояснения по каждому пункту.


1. Нормальная документация. По себе знаю, что программы, встречающие пользователя пустым листом, заранее могут вызвать страх и отторжение. На данный момент, увы, приходится лишь уповать на сходство синтаксиса с привычной формой записи выражений в физике, а о всех возможностях и особенностях узнавать, тыкнув у меня в жж на тег PhysUnitCalc и прочитав все записи от начала (самые давние) до конца. Я начинал писать некую статью, поясняющую, почему решил реализовать этот калькулятор (в первую очередь лежащую в его основе библиотеку PhysUnitLib) именно так, а не иначе, но требуется и более прозаичный мануал, как я это вижу - с кучей перекрестных ссылок.

2. Версии для Linux, Android, OS X, iOS. Тут, вроде, всё понятно, мне и самому не хватает этой программы на андроидовском смартфоне. С Линухом и OS X все не так страшно - друг при мне запускал PhysUnitCalc на эмуляторе, замечательно все работало, очень шустро (все-таки, найти значение выражения - задача невообразимо простая для компьютера), но "родное" приложение было бы совсем замечательно.

3. Улучшенный разбор выражений. К существующему синтаксическому анализатору три претензии:
- для него выражение может быть либо верным, либо неверным, тогда как неплохо было бы иметь еще вариант "выражение может быть дополнено до верного", т.е пользователь пока еще не закрыл скобку, что явный криминал, но не надо выделять выражение красным, это пугает. А вот если он уже написал несуществующую единицу измерения или математическую функцию, то надо сразу ему на это указать, иначе тоже обида - "раньше не мог предупредить!?"
- не самый подходящий приоритет операторов: оператор присвоения физической величины имеет приоритет выше, чем любые арифметические действия, включая унарный минус и возведение в степень. Проявляется при работе с температурами и логарифмическими величинами:
запись -20 дБВ приведет к ошибке, потому что мы сначала числу 20 присваиваем размерность - децибел-вольты, а потом пытаемся нашей величине (напряжению) поменять знак, что в децибелах выразить невозможно. Та же проблема с температурой: -20 °C воспринимается как 20 °С, взятые с множителем -1, приводит к полному бреду. Пока и то, и другое лечится добавлением скобок: (-20) дБВ и (-20) °С, но их легко забыть. Подробнее здесь.
- исполнение успело обрасти костылями: поначалу все было просто, рекурсивный разбор "сверху вниз", но когда к обычному порядку действий прибавился постфиксный оператор [] (приведения к заданной единице измерения) и оператор = (присваивание), с порядком выполнения справа налево (в a=b=c сначала считаем b=c, затем a=b), все стало совсем плохо. Есть большое желание переписать весь синтаксический анализатор заново, заодно подучив теорию.

4. Общеупотребительная форма записи различных единиц измерения. Все "именные" единицы измерения у меня введены: ньютоны, паскали, джоули, вольты и т.д. Но действие, к примеру, не имеет собственной единицы, но мы привыкли записывать его как Дж*с, а не кг*м^2/с, равно как и теплопроводность мы пишем как Вт/м/К, тогда как PhysUnitCalc, получив такую размерность, выразит ответ в кг*м/с^3/К. Тут есть два выхода из положения, которые можно использовать вместе или врозь. Мы можем все такие величины тоже внести в файл описания, наравне с именными, а можем написать некую хитрую функцию, которая для неизвестной размерности попробует найти наиболее короткую форму записи, т.е использующую как можно меньше единиц измерения. кг*м/с^3/K - их используется целых 4, тогда как Вт/м/К - всего 3. Но тут есть опасность, что для некоторых величин программа найдет даже более короткую форму записи, но не имеющую ясного физического смысла.

5. Более строгий синтаксис. Не так давно с помощью PhysUnitCalc прикидывал, какая нужна мощность для отопления дачного домика в установившемся режиме и написал сначала строку:
S = 2* 4.5 м * (2.2 м + 1.12 м) + 2* (2 м * 2 м + 0.6 м * 2 м + 2 м * 0.5 м * 0.5)
(площадь поверхности второго этажа - мансарды)
на что был ответ: 41,28 м^2 (с занесением в переменную S)
а дальше я записал
0.039 Вт/м/К / 15 см * S и получил
0,26 кг^2*м^2/(с^6*А^2*К)
хрень какая-то. А так:
0.039 Вт/м/К / 15 см * S [Вт/К]
Некорректное приведение типов: [кг^2*м^2/(с^6*А^2*К)] в [Вт/К]
Не сразу понял, что это было, а все очень просто: буквой S уже обозначался сименс (1/Ом), и когда идет запись единиц измерения, использовался именно он, мы получили 15 см*S. Вот если записать
0.039 Вт/м/К / (15 см) * S [Вт/К]
то получим, наконец, то, что надо:
10,7328 Вт/К
Т.е единица измерения должна следовать за числом, а здесь числа нет, следовательно, это переменная.

В общем-то, поведение программы четко определено и предсказуемо, но грабли те ещё. Может быть, стоит запретить создавать переменные, имена которых совпадают с единицами измерения.
6. Возможность ввести разность температур непосредственно. Сейчас так получилось, что при включении программы она знает градусы, знает фаренгейты, кельвины и ранкины, и только если мы вычтем две температуры друг из друга, появится новая величина °C{dif}, выражающая разность температур, так что 10 °C{dif} [K] = 10 K{dif}. Если после этого самому где-нибудь написать °C{dif}, все будет нормально, однако в начале работы такое выражение попросту будет неверным. Та же история с более странно выглядящими °C{-1}, °C{2} и пр., которых вряд ли когда-нибудь понадобится вводить пользователю, но которые могут появиться в промежуточных вычислениях. Пока я как-то обходился. В тех же тепловых расчетах, вместо °C{dif} использовал просто K и все работало правильно (когда мы получаем производные величины с температурой, типа Дж/К и пр., то температура предварительно приводится к базовой единице измерения - кельвинам), но тоже разок чуть не оступился. Введя
10 Вт/К * 40 °C, я получил 3,1315 кВт, тогда как должен был получить 400 Вт - они и получатся если ввести
10 Вт/К * 40 К, либо
10 Вт/К * (20 °C - (-20) °C), либо, наконец,
10 Вт/К * 40 °C{dif}.

7. Новая функциональность. К примеру, анализ размерностей, а может, работа с кватернионами, векторами, матрицами, но без фанатизма, конечно, делать свой собственный MathCad/Matlab/Mathematica мне что-то не хочется.


Что надо подправить или добавить в PhysUnitCalc?

Нормальная документация
7(21.9%)
Версия для Linux
3(9.4%)
Версия для Android
8(25.0%)
Версия для iOS
1(3.1%)
Версия для OS X
1(3.1%)
Улучшенный разбор выражений
3(9.4%)
Общеупотребительная форма записи различных единиц измерения
4(12.5%)
Более строгий синтаксис
1(3.1%)
Возможность ввести разность температур
1(3.1%)
Новая функциональность
0(0.0%)
Что-то еще (просьба написать в комментариях)
2(6.2%)
PhysUnitCalc не нужен
1(3.1%)
Tags: physunitcalc, программки
Subscribe

Recent Posts from This Journal

  • Я создал монстра!

    Вот нормальная счастливая пара разъёмов ОНЦ-БС-1-10/14-Р12-2-В и ОНЦ-БС-1-10/14-В1-2-В: У розетки кроме основного выступа, отмечающего "верх",…

  • Нахождение двух самых отдалённых точек

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

  • Слишком общительный счётчик

    Вчера я чуть поторопился отсинтезировать проект,параметры не поменял: RomWidth = 8 вместо 7, RamWidth = 9 вместо 8, и ещё EnableByteAccess=1, чтобы…

  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your IP address will be recorded 

  • 6 comments