unit package has reached loadable state (woo hoo!)

--- Robert Dodier  wrote:
> 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. 

Uh - is there a reason for this, beyond presentation?  I've never heard
of a case where mixing them caused problems.

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

OH, I see what you mean:

(%i2) a*z*kg*m/s^2;
                                   a kg m z
(%o2)/R/                           --------
                                       2
                                      s

I'm not sure yet, but I think there might be a way to do this - it
depends on where things are ordered according to the alphabet.  I've
been looking at including Barton's dimension package functionality, and
some of the necessities that entails might also enable me to solve this
problem.

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

My mind is flashing back to the endless debugging of Mathematica
expressions associated with intro physics labs.

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

Sorry, I thought you ment something other than what you did mean. 
We're on the same page now, I think.

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

That would be interesting to look over :-).

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

All of this can be achieved with the letrules setup, if I'm not
mistaken.  I'll have to give it a try, but I think this can be done
without (too much) difficulty.

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

OK, I didn't understand.  The previous concern along those lines was to
the effect that unit names would conflict with desired variable names.

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

I haven't given up on being able to sort things as requested without
using any kind of operator.  The units package has the ability to check
if kg corresponds to a physical quantity, for example.  The question is
whether or not Maxima will let processunits do some final sorting as a
post_eval_function inhabitant without interfering during the display
process.  Anybody know where the sorting of things a->z actually
happens, and how it can be overridden?

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

Yes, I see your point now :-).  But I'm too stubborn to bow to the
necessity of an operator if an alternative exists.

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

I've got it figured out now :-).  Sorry, I thought you were referring
to the maple practice of a*Units(b), which I find distracting.  If a*b
where Maxima has made sure b are the dimensionally active objects is
OK, that I'm in full support of.  I guess most of the scenarios I was
thinking of that involve printing units come down to number*units,
which Maxima already gets correct.  I hadn't figured on variable*units,
although I should have.  Hmm - time for some tests.

CY

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