I'll try writing this again. After composing this once, I had a mail client crash.
C Y wrote: > IIRC the current thought on that is to define tables in Axiom for > unitsystems with the required conversion factors, but that has not yet > been thoroughly discussed, and there is some thinking to do when it > comes to handling things like the Natural (Planck) UnitSystem, which > doesn't really seem to HAVE basic dimensions. The Planck unit system does indeed have orthogonal basic dimensions, but this case raises an interesting point. If you're going to use the Planck system, you need to allow exponents of your dimensions to take on rational values as well as integer values. Frink doesn't allow this currently, for performance reasons, but it may someday. I've built unit systems for other languages (see http://cadswes.colorado.edu/PDF/RiverWare/WehrendPhd_Thesis2002.pdf ) and we found that our users had some units/constants defined in "square root of length" and so on. >> * Try to make all operations constant-time. > > You mean in execution time? Yes. There are other ways of representing relations between units (such as in a graph) that reduce floating-point error, but these will be slower. >> * Allow for a variety of implementations. In Java, this >>translates to defining everything as an interface, and keeping each >>interface as simple as possible. > > What do you mean by implementations? Different unit and dimensional > systems? By this I mean different classes implementing the same interface. >> Some philosophies: >> >> * It makes absolutely no difference what your internal >>representation or base dimensions are. > > Well, we want to define things in a way that makes interesting > operations simple, so to the extent internal representation impacts > that it can be important. I see this as a model-view distinction. >>* Don't try to solve the case of non-linear units within your >>system. Fahrenheit, Celsius, decibel, stellar magnitude, etc., >>are examples of non-linear units with nonsensical zero points. >>Frink implements these as functions which require the user to >>understand the difference between these units and ordinary linear >>units. Doing anything else requires reading minds, which is >>destined to fail. > > Not sure about this - how is reading minds required? It's somewhat > fancier conversion logic, granted, but I'm not seeing how it's > fundamentally different except perhaps for the necessity of > establishing the illegality of temperatures below O deg K, -273 deg C, > etc. Let me illustrate the difference through an erroneous news report that a friend sent to me: -----begin quote ---------------- The extended hot spell has seen temperatures cross the 50 degrees Celsius (122 Fahrenheit) mark. Media reports said the temperature hit 52.1 degrees Celsius (125.8 Fahrenheit) in the northern town of Kottagudam on Monday. The temperatures are about five to seven degrees Celsius (41 to 44.6 Fahrenheit) above normal. ------end quote ----------------- What's wrong with those conversions? The difference is important, so I've decided, rather than guessing what the user means, and often guessing wrong, to be a little pedantic, and show them how their calculation may be ambiguous, and showing them how to fix it. After all, if I help someone to learn something, and think and communicate more clearly, I've done my job. I don't try to read minds, and guess drastically wrong sometimes like the Google calculator does. Case in point. Try to guess in advance what the Google Calculator will return for each the following: 1 F + 1 C 1 K + 1 F 1 K + 1 F + 1 F 1 K + 2 F 1 F + 1 F 1 F / 1 C 1 K - 1 C 1 K / 1 C I prefer unambiguity and a wee bit of pedantry over such unpredictable behavior. Better to teach a man to fish, than quietly slip a squid in his pants... Also see: http://futureboy.us/frinkdocs/faq.html#ParenthesesAroundRight > How do you handle things like radians? Radians are dimensionless numbers. (I had a high-school teacher repeat this three times in a row, and I realize he was talking to me.) In the standard data file, radians are defined as 1. However, if you read the standard data file, you'll see how to easily make radians their own base dimension. I don't do this because it 1.) introduces artificiality into calculations. You end up multiplying and dividing by radians in calculations just to make the units come out "right," when they really were already right. 2.) Frink, by default, uses the base dimensions defined by the SI. The SI threw out radians and steradians as base units in 1973 for similar reasons. That said, Frink is otherwise radians-correct. If you change a couple of lines in the standard data file, it enforces that arguments to functions like sin[x] have angular dimensions, and functions like arcsin[x] will return values with dimensions of radians. All angular measures will have dimensions of radians (or you can even make degrees or gradians into the base angular type, and it'll all still work correctly.) Doing this properly affects the implementation of all trigonometric functions, by the way. However, radians really are dimensionless numbers, and treating them as if they're something different usually makes your calculations unwieldy. I allow it, and designed for it, but discourage its use. > Work vs. Moment of Force, for > example? Since these have the same units of measure, they're internally identical. The only time that the *name* comes into play is when Frink prints out its "helpful" name for that combination of dimensions, or when constraining a variable by dimensions: http://futureboy.us/frinkdocs/#ConstrainingByDimensions The name is otherwise unimportant. Right now it's a 1:1 mapping, which I might change. > Hehe - I'm in trouble. My goal is to handle units and dimensions > "correctly." (I'm still learning what "correct" is.) I agree that > unnecessary complexity is generally undesirable, but I have a feeling > Axiom is going to go a lot deeper into various issues than is "normal." One of the most important suggestions that I can give you to help you be "correct" is to follow the SI guidelines for reading *and* parsing units of measure: http://physics.nist.gov/cuu/Units/rules.html These are largely unambiguous and machine-parseable. Frink follows these rules as its Prime Directives for "correct" usage, and the parsing and default display routines were written appropriately. My tactic is "when in doubt, be pedantic." Help your users to write and read units of measure correctly, and you'll teach them something, and make yourself and them look better. If their input is ambiguous, don't try to silently "do what I mean" and guess wrong. Stop them and make them write it "correctly." Also, don't try to follow the Fortress ( http://lambda-the-ultimate.org/node/view/883 ) tactics of reinventing the rules of mathematical precedence! I hope this is helpful. -- Alan Eliasen | "It's amazing how much mature wisdom [EMAIL PROTECTED] | resembles being too tired." http://futureboy.homeip.net/ | -- Robert Heinlein _______________________________________________ Axiom-developer mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/axiom-developer
