--- Eike Welk wrote:
> You've got me wrong (or I've maybe changed my mind). The present
> situation may be even better when the formula is not dimensionally
> correct. You see the formula more like you entered it and understand
> faster what has happened.
OK. If I can leave matters as they are that is much simpler -
simplification of add was not as straightforward as I had hoped,
although I still think it is doable. If I get bored someday perhaps I
will make it an option.
> What I find nice about Maple is that the variable "m" for mass and
> the unit "m" for meter can coexist in the same formula.
> My main problems are that Maple considers most of the expressions
> that I enter to be errornous and refuses to work with these
> expressions.
The problem is, when you input m, how does Maple know what you mean?
I'm still planning to add the setunitprefix command - will unit_m or
u_m suffice?
> Seeing what you can already do, I have some more ideas for
> improvement. I again change some parts of the Maxima session from
> your first mail.
>
> Assigning quantities to variables should also work with units. This
> is more like people think. Additionally non native English speakers
> (me) don't need to figure out how a quantity is correctly called.
>
> (%i10) assignquantity(t, s);
> (%o10) %time
Doable, almost trivially so if I'm remembering existing functionality
correctly.
> I think it would be really nice to also see the units of the
> variables that have quantities assigned. Something like (again
> missing "^2"):
>
> (%i14) x(t) := x0+v0*t+1/2*a*t;
>
>
> 1 m
> (%o14) x(t) := x0 [m] + v0 t [m] + - a t [-]
> 2 s
This is more difficult - I've got a couple ideas I could look at. What
about having them appear as
(%i2) x0[m]+v0t[m]+(1/2*a*t)[m/s];
a t
(%o2) (---) + x0 + v0t
2 m/s m m
Would that work? I might be able to do that without too much trouble.
Otherwise it's back to nformat and lisp again (groan). It may end up
there anyway - we'll have to see.
> When you substitute a variable by a values it could look like:
>
> (%i14) ev(%, v0=5*m/s);
>
> m 1 m
> (%o14) x(t) := x0 [m] + 5 t (-) [s] + - a t [-]
> s 2 s
Tricky but probably workable, if the initial display problem can be
licked.
> The output of "dimension" should maybe be more verbose, so one can
> see more easy what is wrong. Really nice would be like this:
>
> (%i15) dimension(x(t));
>
> /* 1 */ %length
> (%o15) /* x0+v0*t */ %length + /* - a t */ -------
> /* 2 */ %time
That would be VERY difficult. Perhaps not impossible, but I suspect
nformat, displa, and all previous functionality would get pulled into
that one. There may be ways of outputing useful info that are less
difficult from a display perspective.
> I focus so much on incorrect formulas, because this is what I have
> most of the time. When everything is correct I can go on and work on
> something else.
>
> Can your code deal with unevaluated differentials? This would be
> great if it worked, for formulas that contain partial differentials.
>
> (%i21) assignquantity(y(t), %length);
> (%o21) %length
>
> (%i22) dimension( diff(y(t), t) );
>
> %length
> (%o22) -------
> %time
My code currently does not, but Barton's more mature dimension.mac
package does. I'm planning to merge that in at some point, but this
dimension was useful as is and much simpler to impliment.
> To me your code seems to be already very usefull, and quite easy to
> use.
Thanks! I'm hoping pretty soon I'll be in shape to propose moving it
from contrib physics and putting the old units.mac in the archive.
(It's just a list of definitions, IIRC).
> > Darn it, I was hoping mtimes would be the only one that needed
> > tweaking. 3am logic I guess...
> 3 am - I got your mail at 4 pm; where do you live? Japan? Australia?
USA, Virginia. Oddities of the mail system I guess.
CY
__________________________________
Yahoo! Mail Mobile
Take Yahoo! Mail with you! Check email on your mobile phone.
http://mobile.yahoo.com/learn/mail