Re: [Axiom-developer] Unit package question

[C Y]

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

> I would rather suggest to write a package
> 
> Mass(R: Ring): Ring == add { ... }
> 
> where Ring should actually be something that allows Float to be
> entered  for R. Maybe even
> 
> Mass(T: with {
>    +: (%, %) -> %;
>    *: (%, %) -> %;
>    ...
> })(R: T): T == add { ... }
> 
> would be a good idea.
> (Well, that is Aldor syntax, but I hope in can be understood.)

Well, about as well as I understand Axiom's syntax... :-/.  I might as
well ask this up front, and I'm sorry in advance if I missed something
obvious and/or am proving myself as intelligent as your average rock:

Is there a tutorial or some such that takes a Category->Domains set of
code and dissects it essentially character by character, answering all
the dumb questions?  Here are some of the ones floating around in my
head which I don't know quite how to answer at the moment.  I'm quite
aware these are an indicator I haven't read and understood something I
need to, so if someone can point me to the correct "Axiom for Dummies"
file I'll be only too glad to fade away until I understand it properly.

Taking this example:

Units(R: Field): Exports == Implementation where
  U == Fraction Polynomial Integer


1)  The syntax (R: Field) - what does this actually denote?  R I guess
is all Rings?  I don't know how to parse this statement - is : a
separator, an indicator that R is being restricted to Field (whatever
that is) or what?  Why is it there at all - I'm assuming it has
something to do with letting Axiom know about the existence of the idea
of <something>*Units?

2)  Exports == Implementation - what is actually being exported here,
and where is it being exported to?

3)  U == Fraction Polynomial Integer  I'm assuming this is part of the
Export - I'm also guessing the $U at the end of the units.spade file
somehow ties off the domain definition?

4)  What is the significance of "%" within a domain definition?

5)  Is there a file in the mnt/linux/doc directories somewhere that
gives a detailed description of the syntax of Axiom's spad code? 
Clearly I need to write a new parser in my head.

What does it mean to define "Exports" from a Category or Domain?  Are
Exports visible to the user on the command line or do they manifest
themselves in the parent Category?

If "Domains" are to be part of a "Category", what responsibilities do
the Domains have to a) label themselves as being part of a category b)
export anything back to the Category?  Can a Category demand certain
abilities or actions be defined for a Domain in order for it to be a
legal part of the Category?

> In the "add" part the units could be implemented as variables
> (together with some rules to convert from kg to ton or so) of a
> polynomial domain. The output would be entirely left to the Mass
> domain. And the advantage of that approach would be that one could
> have also variables in the domain parameter R. Nothing prevents it 
> from being something like a  polynomial domain. One only has to 
> take care that variables and units are separated accordingly.

The gotchas there (which I suppose might be sidesteped somehow and I'm
not seeing it):

There are a LOT of conversions to implement.  This is a significant
part of the grunt work of creating a units package, once the core logic
is in place.  At an absolute minimum, I would suggest having a "pivot"
unit defined for each dimensional domain and define all units in terms
of the pivot unit.  Then the autoconverters can do two conversions and
the definitions file is only 2*n instead of n^2 in size.  I got fancy
in Maxima and handled metric prefixes automatically, but Martin didn't
think that would be a good idea here.

Each "unit" domain (or more properly, dimension domain that defines a
non-basic dimension) needs to know enough about the other domains to
spot significant unit combinations, if we add derived units like Force
into the picture. (We need to for any non-trivial use of a serious
Units package.)  So if we define a Mass domain, a Length domain, and a
Time domain can we somehow define a derived domain which recognizes and
handles the combination Mass*Length/Time^2 as Force?

> Then I could imagine to write
> 
> kg:=kilogramm$Mass(Float);
> ton:=ton$Mass(Float);

This we would want to create as the "units database" for the default
package.  Ideally, loading or activating the units package should have
all those definitions prepared and ready.

> mass:=7.3 * ton + 4.3 *kg
> 
> which would print in kg, say, as the standard format.
> 
> 7304.3 * kg
>                            Type: Mass(Float)
> 
> If you like to see this in tons then say, for example,
> convert(mass, ton).
> 
> Well... that is just a thought.

It's a good thought, and is similar in some respects to what I tried in
Maxima.  

> If you like more units than just mass, I think, it would be
> reasonable to write a Unit domain similar to the Mass domain 
> given above incorporating also seconds, hours or whatever.

--- Martin Rubey <address@hidden> wrote:

> Dear Ralf, CY,
> 
> in fact, I like this idea even better than mine. In private
> communication, we developed the domain below, but your idea is
> conceptually better, I think. The full blown thing would then be 
> a category Units, that has as domains Mass, Time, Length, ... I
> suppose.

>From what little I do understand, I like this idea the best of any so
far.  I would call the category Dimensions, since that's what Mass,
Time and Length denote - they are not units until a specific quantity
like 1 kg, 1 sec and 1 meter is defined.  I would define in each domain
a "pivot unit" - this will be the unit that all other units defined in
the domain will need to be defined in terms of.  (Not necessarily by
the user - I'm sure Axiom could process inches defined as a Length in
terms of centimeters into an internal definition of inches in terms of
meters (probably the most logical pivot unit for Length, although any
could be made to work.)  This maps well into defining units easily and
correctly, since each unit defined can be identified as being part of a
unique domain. Then the rules for using it become instantly clear,
being handled at the dimension level, which with the possible exception
of temperature need not and should not concern itself with the details
of converting between units - at that level the rules for dimensional
analysis can be put in place.  After that it's mostly knowing what's
related to what by what ratio, after all.  Then variables can be
defined as being part of the Mass domain, and only accept as
assignments units which are also part of the Mass domain.  Perhaps, if
this logic makes sense at the Category level, an awareness of the
relationships of domains could be encoded.  Simplification of base
dimension combinations into derived combinations is a tricky thing to
create a workable interface for - you have to allow the user to say
things like "I want to simplify base units to Energy when possible, but
not to Force" and then allow them to change their minds later.  Then if
they want you to simplify to BOTH Energy and Force (not a readily
physical situation but it should be handled since predicting all
meaningful unit combinations is an exercise in futility) you must first
check for Energy, and then Force, else you simplify to Force first and
then don't recognize that Force+remaining base dimensions allows for a
further simplification to Energy.  Ideally Axiom would know this, but
it gets tricky because you don't want to ONLY know about simplifying a
dimensional quantity containing Force to Energy - what if the user has
disabled simplifications to Force?  You need to be able to recognize
Energy out of "lower level" dimensions as well...  The answer to this
in Maxima was to define an "order of searching" for derived dimensions,
and then reduce all expressions internally to base units for the
search.  I don't know the best way to approach this in Axiom.

Cheers,
CY


                
____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs