Re: [Axiom-developer] Unit package question - Reply to 1st half

[C Y]

On Thursday 01 September 2005 07:33 am, William Sit wrote:

> SECOND: Extend the Rep in these domains to include units and conversion
> factors.
>
>    Rep:=Record(value:S, dim:Dimension, unit:Unit, factor:(Float, String),
>                absfactor:(Float, String))
>
> My original proposed Rep is simpler because I was not planning for dynamic
> changes to the unit system, so unit and factor (which would be 1 always)
> are "hard-wired". The more general record allows more flexibility. This is
> slightly less efficient in terms of storage, but not that bad, because no
> matter what, somewhere, the system has to store the conversion factors. The
> conversion factors can probably be implemented in a UnitConversion domain,
> which would be a lookup table (maybe tables), which drives the 'setDimUnit'
> and 'setUnit' commands. Axiom has a number of data structures with
> extensive tools to create lookup tables (see domains of category
> TableAggregate in table.spad).

That sounds good, I think - I would propose using this more general, flexible 
representation only in a single instance of a Dynamic UnitSystem - SI and CGS 
wouldn't need it, if I understand correctly.

> In the new Rep, besides the unit, two factors are included: One relative to
> the current system (to provide a relative factor to convert within this
> system when a user changes a unit, and one relative to SI (to provide an
> absolute factor to convert between systems: for SI derived unit system,
> just one factor would suffice; but we should aim for uniformity to simplify
> the code). 

Generality is good, but I'm afraid I'm not following - for any given Unit, 
wouldn't all you need to know be the description of that unit in terms of SI?  
Or are you proposing that all UnitSystems use this extended storage record?  
I would suggest using it only for the Dynamic UnitSystems, and then you have 
the flexibility to define new units in terms of SI which have no existing 
Static definition.

> Each factor has both a value (Float) and a name (String). The 
> value of the factor is when numerical output is needed, that is, when S is
> coerced to Float (via the "lift" mechanism). The name would be used in
> output for symbolic computations to indicate a conversion factor is needed,
> without spoiling the elegance of symbolic computation or more importantly,
> going outside the domain S. It is only a decoration in the output (so it
> can be used with even Float alone), but it serves two important roles as
> well: it can be used as an index key to the UnitConversion table(s) to look
> up the value of the factor, and it can also be used to provide an audit
> trail in numerical computations: typically, if the answer is simply in
> numeric form set to the user's unit, the user may not have any idea of how
> what factors are used in its computation; by delaying the use of numerical
> values for conversion factors, the user can track each conversion in
> symbolic form for numerical inputs to verify correctness and then compute
> when everything is ok (in case there are bugs, for example, this can be
> used for debugging too).
>
> The above setup would make the coercion to OutputForm quite straight
> forward and uniform (which should ignore the factors if they are (1.0,
> "1")).

This is definitely interesting, but I'm not sure we want such an ability to be 
the default - I would suggest hiding the conversion factors unless the user 
specifically specifies otherwise.  I like the idea of the ability to 
explicitly show them though :-).

> The following scenario will illustrate the potential problems and I'll put
> in some suggestions on how to solve some of these.
>
> Assuming the above extended Rep:  unit is initialialised to the standard
> one for the system, factor initialized to (1.0, "1"), absfactor initialized
> to (absfactorvalue, absfactorname).  Let's assume the default unit system
> is FPS (foot-pound-second, a non-scientific system still used in the US),
> see:
>
> http://medical-dictionary.thefreedictionary.com/foot-pound-second+system
>
> When a user runs the command:
>
> (1)   ulen: := setDim("Length", len)
>
> Axiom will return:
>
>       len [ft]
>
> but internally, the Rep is
>
>     [value = len, dim = "Length", unit = "ft", factor = (1.0,"1"),
>      absfactor = (0.3048, "ft2m")]
>
> Here the absfactor says 1 ft is 0.3048 m. The name can be constructed
> dynamically using string concatenation using the UnitConversion table.

In general, I like this (I would prefer to simplify the setDim("Length", len) 
syntax as mentioned in the previous email, but I don't know if anyone else 
agrees with me as to whether my proposal there makes any sense.)

> (By the way, you can find lots of conversion factors on line: for example
>  http://www.onlineconversion.com/
> Just learn a bit more! Let's just stay with English for this discussion.)

Heh :-).   We need some "official" source for the various standards and 
conversions, I think - NIST conveniently supplies the SI definitions, but 
beyond that I'm not sure where free, official online info would be.

> In a STATIC change environment (this is, at compile time), if the user
> prefers "in" GLOBALLY as the unit for length, the command
>
> (2) setUnit("Length", "in")
>
> Here is a design question: we can let setUnit("Length", "in") to modify
> ONLY the unit of the "Length" dimension and not any derived dimension that
> involves "Length". This would be the most flexible so that we can allow
> will change the state-vector to reflect all units that involve a "Length"
> dimension as component

Yes, I agree - don't update the derived dimensions.

> len ft2in [in]
>
> with the internal Rep now:
>
>    [value = len, dim = "Length", unit = "in", factor = (12, "ft2in"),
>     absfactor = (0.0254, "in2m")]
>
> where 0.0254 can be computed from 0.3048 by dividing by 12, some other
> means. The absfactor will faciliate converting FPS to SI, and hence to
> other system as well.

I'm not sure about the need for two factors, except perhaps as a matter of 
efficiency in avoiding common conversion lookups - is that the reason?

> If the user prefers "cm" as the unit for length in an otherwise FPS system,
> the command unitLength can be modified to produce:
>
> (3)   len ft2cm [cm]
>
> with the internal Rep now:
>
>    [value = len, dim = "Length", unit = "cm", factor = (30.48, "ft2cm"),
>     absfactor = (0.01, "cm2m")]
>
> This is all not difficult for STATIC changes, that is, changes that are
> effected at Axiom start time. Now consider DYNAMIC changes: suppose again
> the default is FPS system, and the user has already set the variable ulen
> as in (1).

Hmm.  Need to roll around in my head some more :-/.

> Now if the user later runs:
>
> (4)    setUnitLength("cm")
>
> What does this involve? You are now in a run-time environment, you cannot
> change the code for unitLength in the FPS domain, you can only change data.
> (Code modification is in theory possible if you know enough, but I don't
> think that is a good practice in Axiom).  To handle FUTURE assignments, we
> can design the code for unitLength to depend on a state vector for the
> domain: this state vector stores one unit for each dimension, and is
> updated by the setUnitLength and similar commands. The unitLength (and
> similar commands) can check this state vector before generating the Rep.

Sounds good, in broad.

> But what about those variables already defined, like ulen defined in (1)?
> If ulen is used in some computation requiring ulen to be an input
> parameter, then we can update it. For example, if the user now wants to
> compute the area for a square with side ulen using one of the following
> syntax:
>
>      uarea := ulen * ulen
>      uarea := unitArea(ulen, ulen)
>
> the routine * or unitArea can check the units of its arguments and update
> them before computation. However, if the user simply types
>
>      ulen
>
> the interpreter can only redisplay the output (1). The interpreter has no
> reason to call the FPS(S) domain to perform an update and change the unit
> of ulen and display the output (3). Perhaps the domain FPS(S) should
> provide a function update(ulen).

Does that mean an interpreter update is needed.?

> I made the factor:Union(Float, Symbol) to allow a delay of the computation
> when symbolic computation is more prevalent and also when S does not have
> RetractableTo(Float).  This still requires S to have RetractableTo(Symbol).
>  The exact meaning of factor needs some discussion: perhaps there should be
> two factors! One relative to the current system (to provide a relative
> factor to convert within this system when users changes a unit, and one
> relative to SI (to provide an absolute factor to convert between systems).

I think the latter is a matter of convenience - converting relative to the 
current system is also doable via input unit -> SI -> output unit - if I 
understand you what you are doing is precompressing this two step process 
into one for the default "output" system?

> > I think this is a weak spot in my understanding of dimensionality, so I
> > apologize if I'm being dense here.  If we take C=%pi*d where C is a
> > circumference, %pi is %pi, and d is diameter, and look at the
> > dimensions, we have:
> >
> >           degree
> > Length =  ------ Length
> >           radian
> >
> > Casually, this doesn't look at all balanced.
>
> Of course not. But that is exactly the point: a dimensionless constant
> takes on different dimensions in different conversions or equations. So
> even thought these have the same VALUE pi, the pi in C = pi*d and the pi in
> 180 deg = pi radians are different because their (hidden) dimensions are
> different. In each equation, only their values are the same.

OK - so how to we represent this in a  CAS?  Or more specifically, what about 
the fact that a dimensionless constant has dimension that cancels is useful 
for us to display, and how do we go about it?

> > Does it mean that when we
> > define the dimensionality of the variable C we need to define it as:
> >
> >  degree
> >  ------ Length
> >  radian
> >
> > rather than just Length?
>
> No, dimension of C is length and is not dependent on any equation it is in.
> This is a major difference between physical quantities and mathematical
> constants.

So we are going to have to distinguish between them somehow?  What do we want 
there?

> Perhaps we should start using the term "dimension" to mean the 
> one used in the definition, which may involve derived dimensions, and the
> term "reduced dimension" to mean a simplified form in terms of the basic
> dimensions. Then we can say the reduced dimensions of pi in both equations
> are the same, namely 1 (or dimensionless), but the dimensions are
> different. This terminology would work to say work and moment have the same
> reduced dimensions, but their dimensions are different (when vectors are
> used to indicate the direction of the distance with respect to the forces).
> How vectors may be expressed in dimensions is another thing to study.

YES!  This is an excellent suggestion, and might provide a way to address an 
issue that has been bothering me:

Let's say we work with both work and moment, in two different equations, and 
both calculations would simplify down to length if we cancel out units.  
Presumably those lengths have the same dimension, but they sprang from two 
different equations that would not be the same dimensionally if I were to use 
proper derived dimension simplification rules, despite their both winding up 
with a length falling out.  I think being able to say work and moment have 
the same reduced dimensions would allow us to perform calculations, simply 
noting that the length is a reduced length by virtue of being calculated from 
a quantity involving ambiguous substitution.

Hopefully that was clear enough to express my concerns.  I don't know if they 
would crop up or not in the "real world" - if this is too confusing I can try 
and construct an example (gulp).

> May be, or may be not. It depends on the physical meanings of the
> variables. If I have price at $5/m multiplied by 7 m, I should get $35. If
> I have 8 N divided by 2 m^2 for pressure, and N has dimension kg-m/s^2, is
> it ok to cancel one of the m? So a single rule of Length (m) is not
> applicable to all cases.

This will need to be handled, somehow.  Are there any good references that 
contain the applicable rules for us to implement?

> Actually, you scenarios are not narrow but general and right! There should
> be no difference between units as used by students and units as used by
> researchers. The idea of units is not limited to even SI. Currency
> conversions are conversions in monetary units. But we should be able to use
> Axiom's unit system for grocery as well (Back to my unfinished idea on
> different Dimension domains)! Dimension=Union("Orange", "120z-Coke", ...)
> is as useful as Dimension=Union("Mass", "Length", ...). (Yes, a supermarket
> manager using  Axiom, that'll be the day: not so far-fetched if you think of 
> the operation  research problems involved).

Heh - neat :-).  But it does raise some awkward questions, which came up 
briefly earlier but escaped my notice:

You mentioned $ interacting with meters, and in a previous email kilobits and 
kilobytes were also mentioned.  Unfortunately, neither money nor bits of 
information are covered by any combination of SI units I am aware of.  So 
perhaps our top level category should be not simply Dimensions but 
PhysicalDimensions, and we could perhaps implement some other Categories for 
Dimensions not covered by SI (like money and bits, both of which are Basic 
Units as far as I can tell).  Money might be defined in terms of other things 
in some sense, but that definition is as complex as society itself and ever 
changing.  Fascinating issues, but perhaps those should wait for later.  
Indeed, does it even make sense to include a concept like money in a system 
intending to stick to strict mathematics as much as possible?  I suppose yes 
since we can think of practical uses, but thinking about it is making my head 
hurt ;-).

Again, sorry William if my comments are not well informed/useless.  I think my 
two concrete suggestions worth considering might be to use a hash table of 
all units for mapping operations, and to allow two types of UnitSystem 
definitions - Static, for unchanging (or not normally changing) definitions 
like SI, and a Dynamic environment set up to use your records idea to be 
flexible and responsive to the user.  As a reminder, feel free to ignore me 
since you are clearly much further and better versed in this than I am.

Cheers,
CY