On Tuesday, May 19, 2015 13:44:33 Mark Henschel wrote: > Pierre: > Also don't forget Astronomical units and also Parsecs, neither or which is > part of SI.
The astronomical unit is precisely known (and now defined) in meters, and the parsec is a radian-AU per arc second. So there's no problem entering data in parsecs, storing them in meters, and displaying them in parsecs. Same with the light-year; the year used and the speed of light are both defined exactly in SI units. The sun's mass, though, is not precisely known. It is calculated from the precisely known AU and year and the imprecisely known gravitational constant. On Tuesday, May 19, 2015 21:09:03 Martin Vlietstra wrote: > 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. Another surveyor gave me some data from a topo he did so that I could test the program on data I didn't generate. I read the data in in feet and exported them in both feet and meters. (The native file format will have all lengths in meters, but it exports in feet or meters files which are loaded into data collectors.) The X and Y coordinates, which are all near 50000 ft, came out as read in when written in feet, but the elevations, which are around 920 ft, came out ending with "00000001" or "99999999". The reason is that the coordinates in meters are around 15200, which is slightly below 16384, but the elevations are around 280, which is a little bit above 256. The Sunday before last I profiled the program and found that it was spending the most time (not counting time spent in manysum, which had a long test routine) in area3, which computes the area of a triangle given the coordinates of its corners. For numerical stability (it's used also to tell how two line segments intersect), it sorts six products before adding them. I unrolled the sort loop and replaced it with a sorting network, which resulted in taking 1/3 as much time. > 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. That's not an SI problem, that's keeping local time with summer/winter time changes. Pierre -- .i toljundi do .ibabo mi'afra tu'a do .ibabo damba do .ibabo do jinga .icu'u la ma'atman.
