В каких единицах измерения вы будете хранить технические данные?

Question

В нашем приложении в настоящее время мы принимаем решение о сохранении всех инженерных данных в нашей базе данных в SI.

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

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

Когда мы «стандартизируем» число, т. Е. Когда мы конвертируем это количество для нашей собственной настойчивости, мы можем преобразовать его в Па (Паскали), что потребует либо умножения, либо деления числа на некоторое другое потенциально большое число.

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

В настоящее время мы используем ORACLE float и System.Double.

Что люди думают об этом?

UPDATE

Дальнейшие исследования обнаружили Единицы измерения поддерживают на следующем языке F # (в CTP, как я пишу).

Кажется, мы сможем понять F #, как пользовательский ввод, например:

9.81<n/s^2> // an acceleration

Мы также сможем создавать наши собственные производные юниты и системы юнитов.

_{(источник: msdn.com )}

Answer 1

Имейте в виду значимые цифры - точность измерения. Если PSI известен только как целые фунты, то после преобразования в Па есть 15 десятичных знаков, все еще остается только одна значащая цифра.

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

---

Edit:

Вы также можете рассмотреть возможность использования NUMERIC(p,s), где точность (количество цифр) и масштаб (число цифр справа от десятичной дроби) могут быть явно указаны.

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

Answer 2

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

Используя приведенный вами пример преобразования PSI в паскали (1 PSI = 6 894,75 в год), если я измерю, скажем, 14,7 PSI и переведу его в паскали, я получу 101 352,825. Это слишком много точности. Вам необходимо сохранить это значение как 101 000, чтобы отразить реальную точность измерения , а не вычисления .

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

Answer 3

Я думаю, что технические данные обычно недостаточно точны, чтобы беспокоиться о разнице. Вы знаете выражение инженера: «измерить микрометром, пометить мелом, порезать топором». Это о суммировании. Беспокоиться о разнице между 8 значащими цифрами или 12 в расчете на что-то, что построено в реальном мире, и терпимостью к 2 значимым цифрам просто не имеет смысла.

Answer 4

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

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

Answer 5

Ну, это зависит от того, насколько точным ты хочешь быть. Помните, что когда речь идет о разработке, недостаточно просто хранить число 3,20, потому что 3,2 не то же самое, что 3,20, когда речь идет о разработке. 3,20 подразумевает более высокую точность, чем 3,2, что может быть 3,15 <= x <3,25 </em>.