If you have the luxury of designing the software, you should be careful
about using floating point numbers - they can create all sorts of problems.

A number of years ago I had to design a system that accepted logs of
electrical data that was taken at various points around Italy.  The data was
collected at quarter-hour intervals, 24x7. The time system that I devised
was to number the quarter hour starting 00:00 UTC on 1 Jan 2000 as interval
1, the quarter hour starting at 00:15 UTC  on 1 Jan 2000 as interval 2 etc.
All input data was converted to this format. A database table kept track of
when the clocks went forward and when they went back, thus most days had 96
intervals, but one day a year had 100 intervals and another had 92
intervals. 

Thus time was not strictly SI.  BTW, towards the end of last century, I
worked on four different Y2K project - three serous project and a
non-serious project at http://www.windhorst.org/calendar/. 

Maybe this will help you.

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf
Of Pierre Abbat
Sent: 19 May 2015 16:32
To: U.S. Metric Association
Subject: [USMA:54710] software that uses measurements

Other than astronomic (stars' masses are known more precisely in sun's
masses than in kilograms), atomic (charges are integral numbers of
elementary charges but unround numbers of coulombs), and angular (angles are
often expressed as turns divided by an integer rather than radians), are
there kinds of data that should be stored in non-metric units?

Suppose you're writing a software program that handles measurements, and the
data have been expressed in both metric and non-metric units. How do you
handle input, storage, and output of data?

I'm writing a surveying CAD program called Bezitopo. All data are stored in
floating-point coherent SI units, except angles, which are stored in
fixed-point
2^-31 turns, unless they're defining a position on the earth, in which case
they will probably be stored as floating-point radians. Lengths can be input
or output in meters, international feet, US survey feet, or Indian survey
feet, but they are always stored in meters.

LandXML has a tag that says what units measurements will be stored in. They
can all be meters, or they can all be (US or international) feet.

Pierre
--
La sal en el mar es más que en la sangre.
Le sel dans la mer est plus que dans le sang.



Reply via email to