Maple Units package



--- Eike Welk  wrote:
>
> I want to use m, l, s ... as variable names (formula symbols). 
> Otherwise I'd have to use something like: var_m, var_l, var_s. I 
> think it would be quite confusing when many commonly used symbols 
> would suddenly have a special meaning as unit names. 

Hmm.  OK.  For me this would be bad practice, since my brain would see
m in a unit context and make the obvious assumption, but I can see how
other people would be different.
 
> An easy workaround would be using a common prefix like: unit_m, 
> unit_l, unit_s.

I guess what I could do is assign a unit prefix which can be appended
to the unit definition arrays.  E.g. the program could go through and
stick unit_ on all current unit names.  Something like :

setunitprefix("unit_");

> Yes, chemical reactions are always present as ratios in mol/mol or 
> g/g. As mol(O2)/mol(H2) the units are much more usefull. 
> 
> I consider this an advanced feature, which can wait. In Maple, the
> way  I use it seems not to be documented.
 
I think this would make more sense as part of a chemistry package which
makes use of the units package.  I could add all interesting periodic
table information while I'm at it :-). 

> > Can you give an example of what it means for them to "know" about
> > units?  How are they treated differently?
> 
> Here it is:
> >diff((5/2*t^2 + 2*t)*Unit(m), t);          #wrong
>               (5*t+2)*Unit([m])
> >diff((5/2*t^2 + 2*t)*Unit(m), t*Unit(s));  #right
>               (5*t+2)*Unit([m/s])
> I don't know how usefull this is. To me this seems like a workaround 
> for the fact that variables (symbols) can not be associated with a 
> dimension.

In essence, yes.  I will think about how to handle that.  It is not
clear to me whether diff needs to know about this, although I suppose
it might.  I get a cold chill or two when I think about messing with
those functions, so that will probably have to come later and will
require review by the list.  I know of no clean way to currently define
specific derivative behavior short of writing my own function.
 
> Trigonometric functions know of units too:
> >sin(Pi*Unit(rad)); sin(180*Unit(deg));
>        0
>        0

Those can just be defined as numerical constants with %pi in them, I
think.  Not hard.


> I think this should produce a plot:
> plot(2*Unit(m/s)*t, t=0..1*Unit(s));
> There are offcourse several problems to solve. What should e.g.
> happen here? Two axises?
> plot([Unit(m/s)*t, Unit(m/s^2)*t], t=0..1*Unit(s));

Um.  Will need to think about that.
 
> This offcourse works:
> >convert(2*Unit(m/s)*t,unit_free): #remove units
> >plot(%, t=0..1);

That's the easy way, of course.  That should be easy to impliment -
just substitute 1 for all units.

> I gave a bad example. Maple's simplify returns an error with the
> above expression. In the following example simplify should combine 
> the two  terms that contain units (I think), but it gives an error
> message:
>
> simplify(2*Unit(m/s)+3*Unit(km/h)+v1);
>    Error, (in Units:-Standard:-+) the units `m/s` and `1` have
>    incompatible dimensions

I believe Maxima will be able to do that:

Maxima 5.9.1.1cvs http://maxima.sourceforge.net
Using Lisp SBCL 0.8.20
Distributed under the GNU Public License. See the file COPYING.
Dedicated to the memory of William Schelter.
This is a development version of Maxima. The function bug_report()
provides bug reporting information.
(%i1) load("./units.mac");

(%o1)                              ./units.mac
(%i2) 2*m/s +3*km/hr + v1;
                                     10800002 m
(%o2)                           v1 + ----------
                                         s

> The problem is: Maple is too picky. I can't even assign this 
> expression to a variable. I get the same error as above.
> >e_5:=2*Unit(m/s)+3*Unit(km/h)+v;
> 
> An annoying error is that even removing units does not always work:
> >convert(v=2*Unit(m/s), unit_free);
>        v = 2*Unit([m/s])
> 
> But this works:
> >convert(2*Unit(m/s), unit_free);
>        2

Hmm.  I'll have to think about what the equalivent situation would be
in Maxima.
 
> Thanks for considering my suggestions, and excuse me for the late 
> answer.

No problem.  I'm always amazed how subtle some of the issues
surrounding units really are.  Hopefully Maxima will eventually be able
to do most of what you want.

CY


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - Find what you need with new enhanced search. 
http://info.mail.yahoo.com/mail_250