Re: [Axiom-developer] Unit package question

[C Y]

--- Ralf Hemmecke <address@hidden> wrote:

> Hello Clifford,
> 
> Aldor is much clearer than SPAD. You will agree on that when you
> later have to understand what you once have written in SPAD.

Hehe - hence's Tim's focus on literate programming becomes important,
although I note at least some of the dvi files produced by my latest
Axiom compile were less useful than I had hoped and had some rendering
issues.  However, it is so incomparibly better than the Maxima source
code situation I'm not dismayed :-).

> I think you should try to ask Stephen Watt, whether the Aldor
> compiler will ever become open source. He claims that there is 
> still some copyright issues to be solved. But I don't know which.
> Maybe it helps if many people ask him for opensourcing it. I would
> be very much in favour of it. Peter Broadbery once worked with NAG 
> on Aldor and I think he could do wonderful things with making the 
> Aldor compiler better. Anyway at least he could document the code 
> properly that he added to the compiler. So I rather ask you to help 
> making Aldor free.

With pleasure.  I like Martin's idea of a petition - getting some big
names on board would help.  I had assumed it was impossible - some
communication I remembered from long ago had indicated that there were
commercial ambitions for Aldor and that would preclude open sourcing it
- perhaps I misunderstood or the situation has changed.  That would be
very good news indeed. 

> > I guess I was thinking something like a Category Dimension and the 
> > various Domains (Mass, Length, etc.) as members of that Category. 
> > Sounds like that might not be the right way to work things though.
> 
> Right. The reason is: what do ALL dimension domains have in common? I
> cannot think of a single function, except, maybe "convert".

Well, yes and no - I agree functions might be limited, but there are
other things.  They all have in common the rule that you can only add
dimensions if the dimensions being added are the same.  They all have
the same requirement for display formatting - e.g.:

    kg*m                a
 23 ----,  23a N, 25 K, - Ohms, etc. 
      2                 b
     s

All metric units share the same prefix convention both for full names
and abbreviations (the programmer in me wants to use that, but I
concede it might be better in the Axiom world not to, though I have not
given up yet).  There are rules that work for all units which tell you
what the units would be for operations like integration even if you
don't DO the integration (see Barton Willis's dimensional analysis
package - I'm not sure how formalized those rules are there, but they
do seem useful.)  There could be global settings which might
potentially apply to multiple dimensions  (like, say, don't use derived
dimensions at all - report everything in base dimensions.)  That kind
of thing was why I thought a category might be useful (not fully
understanding the purpose of categories, granted) but if it would make
it hard to multiply dimensions like Mass*Time then it's a bad idea -
the very notion of derived dimensions rests on those operations.
 
> > OK.  What about this - have two domains, Dimensions and Units. 
> > Have Units depend on Dimensions and define its units in terms of
> > Dimensions.
> 
> He? Maybe I am missing the difference beteen dimensions and units.
> What is what?

A dimension is an abstract concept of a physical property, whereas a
unit is a description of some specific instance or manifestation of
that property.  For example, Length is a dimension, meter is a unit
describing the dimension Length.  Inch would also be a unit describing
the dimension Length, and because they both describe the same dimension
it is legal to consider things like 2*meters+3*inches.  By the same
token, Mass is a dimension, kg is a unit describing the dimension Mass,
and a slug is also a unit describing the dimension Mass.  So
3*kg+2*slugs has meaning, because the dimension of both terms being
added is the same.  However, 3*kg+2*meters is not legal, because
although both are units the dimensions each of those units are
describing a DIFFERENT dimension.

Also, let's consider the equation for parabolic motion:

 x = x0+v0*t+1/2*a*t^2

We know that x and x0 describe distance (e.g. Length), t describes
Time, v0 describes Velocity, which is a derived dimension defined as
Length divided by Time, and a is an Acceleration is a derived
dimension, defined in terms of another derived dimension (Velocity)
divided by Time, or more fundamentally as Length divided by Time
divided by Time.  

We know all this, but if we were to USE this equation we would input
quantities with units, such as 4*m, 5*hrs, 45*km/s, 9.8*m/s^2, etc. 
But we can use ANY units - equally legal would be 4*yottameters,
5*eons, 45*inches/minute, 10*miles/day^2, etc.  Indeed, it is not
uncommon to have some physical constant or experimental data in
inconvenient units - one of the primary purposes of a units package is
to do all the annoying work for you.  So what you want to do is define
your equation, and define the dimension (NOT the units) of the
variables used.  This prevents x0 being assigned 5*kg, but will allow
any unit which makes physical sense to be used successfully.  A
variable has no concept of what unit it is in most physics equations,
for example, and it isn't supposed to know that.  Perhaps constraining
a variable to a specific unit for display could be implimented, but the
check to make there is that it can be converted to the correct unit and
perform this operation automatically. A second option/setting could be
to accept only a form described in the correct unit, e.g. a*meters for
a variable x with set unit meters.  I can see the latter being useful
only to prevent accidental entry of incorrect data, but it might be
useful for that.  Conceptually I would prefer to allow variables to
only know their dimension by default, and require a specific override
on a per variable basis for other behavior, for two reasons:

1)  This allows a global setting to govern the reported units for all
variables, which I think is useful.  If we want to be able to override
this for specific variables I suppose that would be OK (and maybe even
valuable) but I would much prefer the default to be that all
dimensional quantities be reported in the global unit I specify for
that dimension.

2)  It works against the temptation to allow a user from inputing only
a number to a variable and getting a dimensional quantity back.  One of
the biggest problems in introductory labs (and sometimes well beyond
that!) is people who don't write units down.  Sometimes they don't even
KNOW the units, and are just trying to get by without doing the extra
research and figuring out what they are.  (Textbooks sometimes are
unhelpful in this regard, in my experience, so the habit is to be lazy,
manipulate the numbers, and assume everything worked.)  Implimented the
way I have described, a unit will never get automatically assigned to
anything unless a user specifically sets that up, and to do that they
have to know what unit they want.  E.g. even if we define x as meters
and only meters are allowed for assignment, x := 30 is still rejected
as an error.  x := 30 should never be a legal assignment for any kind
of dimensional variable, regardless of settings.  

I think what people are doing, when they say they want to describe the
variable x as being in meters, is that they want the CAS to know x is a
length and to always display it's value in meters.  That I can agree
with, but I would suggest that if such a feature is implimented it be
in such a way that it does NOT accept x := 30 as being an assignment of
the value of 30*m to the variable x.  This is exceptionally bad
practice and should be disallowed.  I prefer that something like the
following be put in place:

DefineDimension(variable, dimension) : This will associate a given
dimension with a variable.  I would suggest that x::dimension be
configured to do this, as well.

DefineDisplayUnit(variable, unit): This will a) automatically assign x
the dimension Length, and b) instruct Axiom to always convert a
displayed value of x into meters, whatever units it was assigned in or
the global settings tell it to display.  I'm not sure if x::unit is a
good idea or not, but probably should be done for consistency. 
Documentation would have to train people to use the more general
x::dimension if they want global unit settings to be workable.

DefineAssignableUnit(variable, unit):  This will allow assignments to
this variable ONLY if the form being assigned is of the form
variable*unit where unit matches the expected unit of the variable.  It
should not enable an assignment without specifying unit.  Perhaps it
should set the output flag of DefineDisplayUnit as well, or best of all
a flag could control whether it does or not, with the default being
yes.

Does this seem to make sense? 

> Ah, I've heard of dimensional analysis once. That rather checks
> whether the type of the result has the correct format. Oh, that 
> somehow seems to suggest the domain way. But first explain. And
> maybe let me sleep then a night about it.

Hopefully the above outlines it - "dimensions are what units describe"
is probably the shortest way to put it I know.  units can share a
dimension, dimensions do not share units.  Dimensional analysis will
report the dimension of an expression, not the units of that expression
(e.g. Time instead of minutes).  It is useful for checking that an
equation gives you the type of dimension you expect - for example if
you define F=ma and dimensional analysis of F gives you Energy, you
know you goofed somewhere (this is less obvious sometimes with units,
particularly in complex cases.)  It also is useful for giving you an
idea of what some quantities in science actually correspond to
physically (also often not as obvious and would be nice.)

Hopefully I'm thinking about all this correctly.  Most people never
need to delve into the nature of units like this - or maybe most other
science types figured this out sooner and more easily than I did,
assuming I've got it right.  Either way, a units package in Axiom will
make it all explicit and documented, if done correctly :-).

> Well, yes, but as far as I understand you want to distinguish the
> type of the units (length, time, mass, etc.). So maybe the 
> metadomain approach would be a good idea.

Distinguishing the type of the units is essential for knowing what
legal operations for "+" are, just for starters.  This is where my
knowledge of Axiom is too limited to know what the good mappings are -
hopefully that will emerge.  I'm pretty sure there IS a good mapping -
it just needs to be hammered out :-).

Cheers,
CY

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com