nabbla (nabbla1) wrote,
nabbla
nabbla1

Таинственная литера "М"

В программе PhysUnitCalc обнаружился досадный баг, когда в некоторых случаях приставка m (milli) может восприниматься как M (mega) и наоборот. К счастью, в большинстве случаев разница на 9 порядков сразу заметна и становится ясно - "что-то не то", но если участвует логарифм, то всяк бывает.

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


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

При запуске программы в ней задана, например, единица "А" (ампер), но нету ни миллиампер, ни микро, нано и пр. Когда мы записываем 10 мА, такая единица генерируется на лету, ведь иначе мы вообще не смогли бы выражать ответ в миллиамперах! Вот здесь и кроется изъян - теперь, если мы попытаемся записать 1 МА (мегаампер), такая единица измерения уже будет существовать, отчего запись будет интерпретирована как 1 мА.

Не знаю, насколько правильным было использовать всю эту систему с идентификаторами. Она хороша тем, что физическая величина занимает мало места (лишь 2 дополнительных байта), а самая медленная часть - получить ее из строки, как только она уже во внутреннем представлении, все операции выполняются шустро. Собственно, эту библиотеку я хочу использовать и в "Михалыче", чтобы отличать цепи разного рода (электрические, гидравлические, тепловые) друг от друга, разбрасывать результаты моделирования по разным графикам (амплитуды напряжения - на одном, амплитуды тока - на другом, а их фазы - на третьем) и иметь возможность строить графики не для непосредственно отмеченных величин (ток через провод 1, напряжение в точке 2 и пр), но и введенные пользователем функции, типа db(abs(U(node1) / U(node2))) или arg(U(node1))-arg(U(Node2)), и при этом выражать свое "фи" выражениям типа U(node1)+I(wire5). Вот и стоял вопрос скорости среди всего прочего, хочется же, чтобы при построении сотни точек не было тормозов!


UPD. И еще один глюк указали: Фаренгейты в Цельсии не переводятся нифига:
> (-40) Fahrenheit [Celsius]
-40,0000000000001 Celsius
Но я проверил, это только -40 не переводится, с остальными полный порядок) И вообще это фича!
Tags: physunitcalc, математика, моделирование, программки
Subscribe

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

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

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

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

  • Балансируем конвейер QuatCore

    В пятницу у нас всё замечательно сработало на симуляции, первые 16 миллисекунд полёт нормальный. А вот прошить весь проект на ПЛИС и попробовать "в…

  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your IP address will be recorded 

  • 5 comments