unit package has reached loadable state (woo hoo!)

Hi Cliff,

Thanks a lot for driving the discussion about units.
It is really an interesting topic.

About separating units from quantities, you wrote:

> Um.  This may be silly, but why would you want to
> extract them?  

If I'm not mistaken the prevailing convention
in science and engineering is to consider quantities
separate from units, both in computation and in
presentation on the page. Dimensional quantities (by
this I mean a dimensionless factor times a dimensional
unit) are universally written with the dimensionless 
part separate from the dimensional part, with the
dimensionless part on the left and the dimensional
part on the right.

About the back tick q`u notation --

> This might be workable, but I shudder at having to
> explain to a new user why they have to write 12`m
> instead of 12*m. 

Well, surely this is an overstatement.

> As an end user myself, I expect to have kg, m, etc work
> like any other quantity, since they are quantities. 
> When I see kg in an expression, to me this is an implicit
> 1*kg, and I would expect to be able to interact with it on
> those terms and not operator terms. 

I'm not sure I understand what you're getting at here.

> (With one major exception - this is not true for temperature,
> which denotes positions on an absolute scale and is tricky
> to convert.  Your notation might actually be a
> solution to the temperature problem.)

I've made up a simplification rule to handle a translation 
and another to handle scaling. So between the two of them,
F <--> C conversions happen.

> I confess to curosity - what utility do you see from 
> being able to separate units from other quantities? 

Well, here are some scenarios. Plotting points -- drop
the dimensional part. Writing a table or a data file --
drop the dimensional part. Computing regression 
coefficients or some other data mungeing -- drop the 
dimensional part. So-called dimensional analysis --
drop the dimensionless part.

> I do plan to add a  setunitprefix command which will
> allow you to do setunitprefix(unit_) and then have
> everything appear as unit_m and unit_Newtons.  This
> would clearly identify which quantities in the 
> calculation were units - would that meet your needs?

Names of that sort, aside from being verbose, would not 
ensure that units are separated from quantities,
so you would still have things like

    unit_m z
    --------
    a unit_s

where you want
 
      z  m
      _  _
      a  s

> > In reference to the second point, I believe the q`u 
> > representation obviates the need for post_eval_functions,
> > since it is now easy to identify the operations requiring
> > processunits: they are just the arithmetic operations
> > involving ` objects. There may be other motivations for 
> > post_eval_functions, but I think units processing can 
> > proceed without it.

> Only if you accept needing ` to work with units. 

I'm not particularly attached to `, but there are not many
special characters not already used. Btw " " is a legal
operator name! However, it must be escaped with a backslash,
so on input one must write it \  , although it doesn't appear
in output:

  infix (" ");  100 \  kg  =>  100 kg

> My philosophy on such things can be summed up as 
> "as close to how it looks and acts in the textbooks as
> can be managed in a CAS." 

I'm certainly in agreement there -- that's why I have
proposed the business with the ` operator.

When I have a moment I'll post the current q`u stuff.
Hopefully it will become clearer with some examples.

All the best,
Robert

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com