Robert,
I believe that multiplication/division is logically a reasonable operation
for units, with the right algebraic properties, e.g. (a+b)*unit == a*unit +
b*unit; unit1*unit2 == unit2*unit1; etc. And of course all of Maxima
"understands" multiplication, so not just simplification, but also solve,
factor, integrate, diff, etc. etc. Which is not true of "`", which was the
problem the original poster was having.
But then, I also agree with you that displaying (e.g.) a*l*z
kilogram-meters as a*kilogram*l*meter*z is poor.
But there is a simple solution to that -- define display_with_units or
whatever which looks something like
display_with_units(ex) := display(psubst([meter=1*meter, ...],ex))$
... or perhaps something more sophisticated.
You also mention separating unit and quantity programmatically; I can see
that there would be a potential efficiency advantage there. But
lreduce("+",makelist(i`m,i,1,1000)) takes about the same time as with i*m
(same for rreduce and tree_reduce, but for xreduce, ` is faster for some
reason...). There is also a theoretical semantic advantage: m ` m could
mean a quantity 'm' of meters. But I'm not sure that's terribly important,
especially when Maxima+ezunits doesn't know that the unit is a constant
symbol, not a variable: ev(m`m,m=2) => 4.
I haven't studied ezunits closely, and I'm sure it contains lots of useful
functionality. The question I'm posing is: how can we get the benefits of
that functionality while preserving the functionality of the rest of
Maxima? For example, how can I solve the following equation for x?:
eq: x`m = 5`ft
Here are some attempts:
solve(eq, x) => [x`m=5`ft] hmm, haven't made any progress
solve( eq``m, x) => [(x`m=5`ft)``m=0] try converting to common
unit in advance; but `` doesn't distribute over =
solve(map(lambda([ex],ex `` m), eq), x) => [(250*x-381)/250 ` m =
0] no better
solve(qty(ex),x) => x=5 oops
solve(map(lambda([ex],qty(ex `` m)), eq), x) => [x=381/250] GOT
IT!
Or to be a little more systematic:
solve(map(lambda([ex],qty(ex `` fundamental_units(lhs(eq)) )),
eq), x)
I would claim that this is too complicated for a simple use case.
I also ran into a few surprises (maybe bugs, but I'm not sure what the
intended functionality is):
* It takes 0.6 sec to calculate dimensions(2`ft), even when calculation is
repeated (so it's not a warm-up effect)
* test: 1`kg+1`ft$ dimensions(test) => mass+length (OK, I guess), but
fundamental_units(test) => kg * m (!)
* qty(1`kg + 1`lb) => 2 -- shouldn't this be an error? or use consistent
(even if arbitrary) units?
* qty(test) => 2 -- shouldn't this also be an error?
-s
On Wed, Oct 31, 2012 at 7:00 PM, Robert Dodier <robert.dodier at gmail.com>wrote:
> On 2012-10-31, Stavros Macrakis <macrakis at alum.mit.edu> wrote:
>
> > I'd suggest you use multiplication (*) instead of the "`" operator
> > throughout your calculation (e.g. 2*m instead of 2`m).
>
> Multiplication makes it more difficult, both programmatically and
> visually, to separate the unit from the quantity. E.g. when b, d, f, and
> h are units, how shall we distinguish units from quantity in
> a*b*c*d*e*f*g*h ? How about a/c*b/d*e/g*f/h ? ('ordergreat' helps a
> little, but not nearly enough, and brings its own strangeness.)
>
> Indicating unit and quantity with a function or operator makes it
> trivial to separate the two, both programmatically & visually.
> Indicating a dimensional quantity with a function is workable (e.g.
> units(a, b)) but needlessly clumsy. When one writes dimensional
> quantities on paper, they are just separated by a space, so I tried to
> pick an operator which doesn't take much ink, so to speak.
>
> > I don't think the ezunits convention works very well with the rest of
> > Maxima in general; the handling of units should probably be rethought.
>
> I certainly put a lot of thought into ezunits, so I suppose it must show
> the limitations of my thinking. As ever, anyone & everyone are free to
> suggest something else, or better still, write the code.
>
> best
>
> Robert Dodier
>
> _______________________________________________
> Maxima mailing list
> Maxima at math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima
>