axiom-developer
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Axiom-developer] Unit package question


From: William Sit
Subject: Re: [Axiom-developer] Unit package question
Date: Tue, 23 Aug 2005 12:59:43 -0400


Martin Rubey wrote:
> 
> William Sit writes:
 
>  > A representation for any of the domains of unitMass(s:S) would be
>  >
>  >    Rep:= Record(value:S, dim:Dimension)
>  >
>  > where Dimension would be
>  >
>  >   Dimension:=Union("Mass", "Length", ...)
> 
> This would not allow for Length/Time

You can add (among the ...) "Velocity" (I already used "Acceleration" in the
examples). Also, we can expand Dimension to a fuller domain that can do
arithmetic, and equating Length/Time as Velocity (but notice that there are
cases where the fundamental units are the same, but the physical derived unit
can have multiple meaning: Length*Force can be Work or Moment, so dimensions
should not be confused with their component basic dimensions).

>  > We need a way to include universal constants, the notation of which 
> depends on
>  > the set S.
>  >
>  > if S has Field then
>  >   unitAcceleration(dv:%, t:%):% == [dv/t, "Acceleration"]$Rep
>  >   if S has RetractableTo(Symbol) then
>  >     accelerationDueGravity == ['g:Symbol::S, "Acceleration"]$Rep
>  >
>  > If S does not have RetractableTo(Symbol), for example S is Float, then we
>  > can use a specific constant such as 9.81 depending on the domain
>  > %:UnitSystem instead of a symbol g.
> 
> This is a nice idea. However, very probably we also need the case of S being
> Fraction Integer. So, as I said in my previous post, we may need to allow for 
> a
> scalar factor of domain EXPR INT to accomodate constants which cannot be 
> thrown
> into S, thus we'd have
> 
>   Rep:= Record(value:S, constant: Constant, dim:Dimension)
> 
> where Constant would be something like Fraction Polynomial Integer, with all
> coefficients equal to one...

I do not follow the role of constant in the above syntax.
 
The "lift" category I proposed can handle this (by enlarging S when needed).
Meanwhile, S most likely should have RetractableTo(Symbol) and hence we can use
symbolic constants within S. My proposal is to delay all the floating point
computations to the end, in a chosen unit system like CGS, and to do those
computations and displays in CGS(Float).

Moreover, derived dimensions (involving arithmetic of basic dimensions) should
only be allowed to be attached to a value domain S if S has the corresponding
operations.

I don't think the use of mixed unit systems in an expression should be
encouraged: one should not encourage the use of 3 meter + 5 feet (not even 3
meter + 10 kilometer) because the answer must be either in feet or in meter or
something else, but only one unit. So the way to handle mixed unit expression
should be to first convert say 5 feet to meter before addition. I would not
worry about such expressions since that is not "scientific" (Axiom: The
Scientific Computation System).

To repeat, my view of units is that units are "decorations" to be handled in the
domains of UnitCategory(S), using a fixed unit system, and by coercion to
OutputForm;and one should adhere to the standards as given by:

http://physics.nist.gov/Document/checklist.pdf


William




reply via email to

[Prev in Thread] Current Thread [Next in Thread]