Re: [Axiom-developer] Re: [Frink] Units

[Alan Eliasen]

   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
  address@hidden       |   resembles being too tired."
  http://futureboy.homeip.net/ |     -- Robert Heinlein