From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,1dd28d5040ded1f8 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-05-17 08:44:15 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!canoe.uoregon.edu!hammer.uoregon.edu!skates!not-for-mail From: Stephen Leake Newsgroups: comp.lang.ada Subject: Re: Announce: Grace project site operational Date: 17 May 2002 11:34:27 -0400 Organization: NASA Goddard Space Flight Center (skates.gsfc.nasa.gov) Message-ID: References: <4519e058.0205150657.3b695758@posting.google.com> <4519e058.0205160543.34b32481@posting.google.com> NNTP-Posting-Host: anarres.gsfc.nasa.gov Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: skates.gsfc.nasa.gov 1021650092 23063 128.183.220.71 (17 May 2002 15:41:32 GMT) X-Complaints-To: usenet@news.gsfc.nasa.gov NNTP-Posting-Date: 17 May 2002 15:41:32 GMT User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Xref: archiver1.google.com comp.lang.ada:24279 Date: 2002-05-17T15:41:32+00:00 List-Id: dennison@telepath.com (Ted Dennison) writes: > tmoran@acm.org wrote in message > news:... > > So it's a Bad Idea to try to make one units package for all the world > > to use, but reasonable ones for reasonable subsets of the world may still > > be a Good Idea. > > Possibly. But if you are talking about subsets for certain jobs, you > are no longer talking about a general-purpose package, which means you > are also no longer talking about Grace. Actually, I think a tool that generates the package on demand _is_ a good candidate for Grace. Well, as long as it's written in Ada :). > > ... Should a single program actually deal with some distances in > > meters, some in centimeters, and some in kilometers, or miles? > > Given > > Typically not. But a general SI package would have to support all of > them, because some users might need meters (flight sims) while others > might need kilometers (space probes). I always use meters for all internal calculations even for space probes. With 64 bit floating point, three orders of magnitude is insignificant. The potential for confusion is too great otherwise. Case in point; I had a nine orders of magnitude error once, because there was a constant that had units of m^3, and someone provided it in km^3. After that, I learned to insist on meters, everywhere. However, user interfaces are another matter. Users want their "favorite units", even if they are non-SI. So perhaps a second package that provides conversion between "standard" and "non-standard" units is needed; it need not provide any other operations on the non-standard units. -- -- Stephe