unit package has reached loadable state (woo hoo!)

--- Robert Dodier  wrote:
> Hi Cliff,
> 
> Thanks for posting the message about the unit package.
> I have a few comments which I hope will be helpful.
> 
> The package you wrote, and the older one, seem to assume
> that units and the quantities to which they attach are 
> more or less inextricable. 

Um.  This may be silly, but why would you want to extract them?  IIRC
this point was brought up in the Maple discussions too, in the form of
asking about something of the form a*Units(b).  I guess I'm missing
something, but I just can't see how this would be useful.  Personally I
find it extremely distracting, but that's just me.

> I think I'd rather see the
> units separate from the quantities, like this: 12`m
> represents 12 meters; a`s represents a seconds; 
> ((a+b)*(a-b))`km^2 represents ((a+b)*(a-b0)) square km; etc,
> using back tick ` as an operator. 

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.  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.  (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 confess to curosity - what utility do you see from being able to
separate units from other quantities?  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?

> Operations on q`u objects
> are suitable for tellsimpafter, for example, 
>
>   tellsimpafter (qu1 * qu2, (first(qu1) * first(qu2)) ` processunits
> (second(qu1) * second(qu2)))$
> 
> after appropriate declarations.
> 
> Such a representation has two merits, I believe. One is
> that it makes a clean separation between quantities and
> units, so that it's clear in every case which is which,
> and it's trivial to isolate either one. The second is that
> it might simplify units handling, so we may be more likely
> to get what we want from the implementation.

I guess it's a question of what you are looking for.  Personally, I'm
not very interested in a separation between quantities and units - I
prefer what I think was called "natural" space in the Maple discussion.
   I would be curious if someone can give me an example of a case where
they would want to separate out units in a fashion which can't be
managed with the current setup or a simple extension to it.  

As to your second point, do you mean it would simplify units handling
by removing the need for letsimp?  I'm a little confused, which I guess
isn't surprising - since I'm writing this to provide what I want, I
haven't realized what's missing yet :-).  What needs do you see this
not meeting?

> 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.  As a user I would be
very reluctant to do so, although I could be a minority of one.  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 think
post_eval_functions (and it's logical partner pre_eval_functions, which
I am beginning to think I might also have a use for) are good features
to have available in general, but again that's one man's opinion.

> At some point in the near future I'll post my half-baked
> tellsimpafter hacks in hopes of better illustrating what
> I'm getting at here.

OK :-).  I'd be glad to look at it.  I must not be thinking very
clearly about how people want to use units - apparently there is a lot
of appeal to the idea of being able to separate out units.  Of course,
this being open source, there's nothing against having two packages
with two different design philosophies available :-).  Each might be
useful for different needs/working styles.

CY

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