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

[C Y]

--- Alan Eliasen <address@hidden> wrote:

> I'll post my initial response to both of the lists you referenced in
> the original mail, as Frink users might be interested in how units
> are implemented in Frink.  Follow-ups should probably be directed to 
> one list or another, or to me personally.
> 
>    The source for Frink is currently not available, but I think it's
> more useful to talk about the high-level design decisions rather than
> particulars of implementation, which may change.

Agreed.  An Axiom implementation of units and dimensions would have to
be done in Axiom anyway, so I'm not terribly worried about source code.

>    As you know, there are lots of different ways that units and
> dimensions could be implemented, and a lot of tradeoffs in
> performance, memory usage, complexity, reversibility, and 
> flexibility.

Indeed.

>    As noted in your mailing lists, I described the implementation
> somewhat in my talk at the Lightweight Languages 4 conference at MIT.
> The slides and video are available at:
> http://futureboy.us/frinkdocs/LL4.html
> 
>    Some design goals are:
> 
>    * Avoid hard-coding of any units of measure or dimensions.  The
> number and base dimensions should be specified at run-time by a
> configurable units file.

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.

>    * Try to make all operations constant-time.

You mean in execution time?

>    * Allow adding of base dimensions at runtime.  This is, in
> practice, very rare and often ill-advised, (in fact, I've *never* 
> had to do it,) but may be a useful construct in some cases.

I have some thoughts about that, but it's down the road.

>    * 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?

>    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.

> * 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.
 
>    There are lots of ways that units could be implemented.  My
> implementation can be described succinctly.  Every unit is a
> combination of a magnitude (as a multiple of some base dimensions) 
> and a list of dimensions and their exponents.
> 
>    The decision to immediately reduce all values to multiples of some
> base dimensions was chosen for performance and simplicity of coding. 

Yes, that's essentially the approach I take in my attempt at a Maxima
units package.

> It has the disadvantage of going through a potential longer chain of
> multiplications than if you kept the relations in a graph.  If these
> multiplications are irreversible, like with most floating-point
> implementations, this can cause problems or precision loss.  Frink
> tries to avoid this by maintaining exact rational numbers when
> possible. (e.g. an inch is defined as exactly 254/100 cm.)

How do you handle things like radians?  Work vs. Moment of Force, for
example?

> I know that this is a rather terse discussion, but hopefully it
> will be helpful.  My primary recommendation is to not make your
> implementation more complex than need be.  Implementing units really
> can be quite simple.  Please let me know if you have more specific
> questions.

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."

>    Other references:
>  * JSR-108, a Java Community Process proposal for implementing
> Units in Java.  This was withdrawn by the leader in 2004.  In my 
> opinion, it's overly complex and hard-coded.  
> http://jsr-108.sourceforge.net/

Thanks for the reference!

Cheers,
CY


                
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com