[Axiom-developer] Re: Units in a calculus problem using Maple

[C Y]

--- William Sit <address@hidden> wrote:

> Dear CY:
> 
> I came across a problem in a calculus text that is an example of the
> kind of care one has to be aware of in dealing with automatic 
> dimensional analysis in CAS.
> 
> From Goldstein, Lay, and Schneider: Calculus & Its Applications, 10th
> ed., Pearson Education Inc., 2004. p. 181, Problem 26:
> 
> A ship uses 5x^2 dollars of fuel per hour when traveling at a speed
> of x miles per hour. The other expenses of operating the ship amount
> to $2000 per hour.
> What speed minimizes the cost of a 500-mile trip? [Hint snipped]
> 
> Imagine trying to do this problem and declaring that x has the
> dimension of velocity. To verify that the expression written down
> to give the cost as a function of x is dimensionally correct, the 
> computer would have to know a priori that the "constant" 5 actually 
> has a dimension. With the proposed design, which allows a 
> declaration of an expression to be of a certain dimension, this can 
> be deduced, and implicitly the dimension for 5 can be ignored.

Hmm.  An interesting case.  For starters, the unit dollars and the unit
miles per hour are not from the same type of UnitSystem - miles and
hours are from Physical Units while dollars is from Economic Units. 
There are no well defined algorithms for correspondance between these
two systems - the equation d [dollars/hour] = 5*(x [miles/hour])^2 is
in fact defining the "translation" from Physical Units to Economic
Units for this particular problem, and even there it is not unique.  I
could say equally well (even in the same problem) that ship2 uses 3*x^4
dollars of fuel per hour.  The conclusion would seem to be that
dimensional and unit equality between different types of UnitSystems is
meaningless as far as ensuring any kind of correctness is concerned. 
The real difficulty is the term "hours" - this is a physical concept,
not an economic one.  Also, we still have the problem of ensuring
correctness in Economic Units and Physical Units respectively - e.g. if
x has specific units fixed at miles/hour we need to ensure any specific
value assigned to x has a) dimension of velocity and b) is converted to
miles/hour before assignment.  Likewise, if we tried to add the cost of
some ship3 which has its costs defined in terms of (say) 2*x^6 cents of
fuel per day to the cost of ship1 we need to make sure that ship3 is
converted to dollars/hour prior to that conversion.  (Assuming dollars
is the "global" currency unit.)

> It would be more natural if one works on the expression level and 
> view 5x^2 by itself of dimension dollars per hour, and to ignore 
> the  than if one is required to declare the correct dimension for 
> the number 5.

Rather than think about 5 as having dimension, I prefer to think that
the Economic Unit System and the Physical Unit System can be delt with
separately.  So, rather than trying to make the jump from velocity^2 ->
dollars/hour, I prefer to address each side of the equation separately
without insisting on Physical Unit equality.  This works since
"dollars" can adsorb any arbitrary Physical Units.  So, in the "short
form" Axiom input, defining this relationship would look something
like:

d := 5*(x [miles/hour])^2 [dollars/hour];

This expression would have a rather complex Axiom type, but the
Physical Unit System would worry about this only insofar as to ensure
that any assignment to x is in terms of miles/hour, and that any
interaction of the quantity dollars/hour with (say) cents/day works by
converting from cents/day -> cents/hour.  After that, it's up to the
Economic Unit system.  So when an assignment to x is made, the Physical
Unit System is the one which will insist on the correctness of any
assignment. The Economical Unit System uses only the numbers, and
coherces the result into the Economic units of dollars/hour, with
dimension <Money>/<Time>.  So now we have some quantity a
[dollars/hour].  If we want to then add b[cents/day] to that, we first
check dimensions -> Money = Money, and Time = Time, so that's OK.  Now
for conversions, we treat the top and bottom units separately.  Money
is an Economic Unit, so the Economic subroutines are called to find the
factor 1/100 and multiply by it.  Because Time is a Physical Quantity,
the Physical subroutines find the factor of 24 and multiply by that.

Essentially, I think the general property needs to be that when
Economic units are involved, dimensional equality needs to be somewhat
redefined.  What the EXACT rules should be I don't know, but this is
why I prefer to stick to physical units until they are fully
straightened out.

> Doing this problem step by step works better in Maple:

> > fuelRate:= 5*x^2*dollars/hour;
> 
>                                          2 [USD]
>                       fuelRate := 1/720 x  [---]
>                                            [ s ]
> 
> Note: NOT 5*velocity^2*dollars/hour;

Here, you have sidesteped the issue by never assigning x any specific
dimension, but treating it like a number.  This is OK, since that's
what would be done by a human working out this problem, but it does
sort of dodge the issue. 
 
> > cost:=distance/velocity * (fixedCost + fuelRate);
> 
>                                   /       2 \
>                                   |      x  |
>                           1800000 |5/9 + ---|
>                                   \      720/
>                   cost := ------------------- [USD]
>                                    x
> 
> > a:=solve(diff(cost, x)=0,x);
> 
>                              a := 20, -20
> 
> > velocity;
> 
>                              1397
>                              ---- x [m/s]
>                              3125
> 
> > eval(velocity, x=a);
> 
>                               5588
>                               ---- [m/s]
>                               625
> 
> > eval(cost, x=a);
> 
>                              100000 [USD]
> So far, so good.

Right - you "hid" the dimensional information associated with x for the
purpose of the calculation, if I understand correctly.  When you solved
for x, you got back only a number.  I'm not sure if this is compatible
with Axiom's approach.

> Why isn't x = -20 not substituted? (Maple's Unit internals expect
> only positive values?)
> And, watch this:
> 
> > x:=20 * miles/hour;
> 
>                                 5588
>                            x := ---- [m/s]
>                                 625
> 
> > cost;
> 
>          281250000 //      1951609       2\            (-1)\
>          --------- ||5/9 + -------- [m/s] | [USD] [m/s]    |
>            1397    \\      17578125       /                /
> 
> Yuks! A student may be at a loss with this. So there seems to be two
> types of symbols: one of which is the kind no units should be
> attached? That would seem very inconsistent.

Hmm.  I need to think about that last expression a bit.

> Will Axiom do better?  Several improvement suggestions for Maple:
> 
> (1) remove all those multiplication operators!
> (2) allow a declaration for the units of x so it can be implicit
> (3) keep the units as inputted as much as possible and get rid of
> those conversion factors (unless specifically asked to make the 
> conversion by the user)

This should be configurable.  Sometimes you want to automatically
convert everything.

> (4) (not sure) allow automatic assignment of dimension/unit to
> numeric constants to balance dimension in an expression (what 
> physicists do) and give a warning

Maybe, but I think keeping Economic and Physical units separate will
help solve a lot of the problem.  I'll take another look later when
I've got more time.

Cheers,
CY


                
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com