In what units of measurement will you store engineering data?

Question

In our application, we currently live with a legacy of the solution to store all engineering data in our database in SI.

I am worried that we might risk not having enough precision and precision in our database or in numerical .NET types. I am also worried that we can see artifacts of floating point math (although this is probably a question for everyone).

For example, raw data may have been expressed (and read with some third-party service) in Psi (pounds per square inch). Engineers chose this unit of measure because (for a pronounced amount) it will tend to give easily digestible, human-readable numbers, without requiring scientific notation.

When we "standardize" a number, i.e. when we convert this value for our own perseverance, we can convert it to Pa (Pascals), which will require either multiplication or division of the number by some other potentially large number.

We often end up storing very large or very small numbers, and worse, we can do further calculations on these numbers.

We are currently using the ORACLE float and System.Double.

What do people think about this?

UPDATE

Further research revealed support for units in the upcoming F # language (in CTP when recording).

It seems we can understand that F # is user input, for example:

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

We will also be able to create our own derived units and unit systems.

creating a derived unit for Newtons in F # http://blogs.msdn.com/blogfiles/andrewkennedy/WindowsLiveWriter/UnitsofMeasureinFPartOneIntroducingUnits_A131/image_thumb_11.png

Answer 1

Remember the significant numbers - measurement accuracy. If the PSI is known only in whole pounds, then after converting to Pa there were 15 decimal places, only one significant digit remains.

Accuracy is different from accuracy, and floating point operations in engineering units should take this into account during operations - do not store more accuracy than the measurement accuracy, do not use more accuracy in the calculation than is known.

---

Edit:

You can also use NUMERIC(p,s) , where precision (number of digits) and scale (number of digits to the right of the decimal) can be explicitly specified.

If this is not an option, consider maintaining accuracy for a particular measurement so that it can be communicated and / or used in the calculations.

Answer 2

I think that as long as you can store exactly as much as you have, you have no reason to worry.

Using the example that you pointed out converting PSI to pascals (1 PSI = 6,894.75 pa), if I take a measurement of, say, 14.7 PSI and convert it to pascals, I get 101,352.825. This is too high accuracy. You will need to save this as 101,000 in order to reflect the actual measurement accuracy, not the calculation.

Keep in mind that any numbers you use for conversion should be no less accurate than your measurements so that you do not lose accuracy during conversion. It is better to have more precision digits (at least one more) in your conversion ratios than in your measurements.

Answer 3

I think that engineering data is usually not accurate enough to worry about this difference. You know that the engineer’s expression “measure with a micrometer, mark it with chalk, cut an ax”. This is about summing up. Worrying about the difference between 8 significant digits or 12 based on what is built in the real world up to 2 significant digits, tolerance simply does not make sense.

Answer 4

To avoid loss of accuracy due to conversion of units of measure, you can store all data received from the measurement in the block in which it was measured. Of course, this means that you can get some pressure values ​​stored in Pa, others in Psi or even mmHg. You must decide for yourself whether this creates more problems than it solves.

And I agree with other answers: in most cases, the accuracy offered by the Oracle platform is much higher than the accuracy of the measurement itself.

Answer 5

Well, it depends on how accurately you want to be. Remember that when it comes to engineering, it’s not enough to just keep the number 3.20, because 3.2 is not the same as 3.20 when it comes to engineering. 3.20 implies higher accuracy than 3.2, which may be 3.15 <= x <3.25.