Re: [Axiom-developer] Unit package question - part 1

[C Y]

--- William Sit <address@hidden> wrote:
>
> Dear C Y:
>
> This long-winded email started more than a week ago and school
> started got in the way. In addition, computer problems, mainly: 
> network and crashing OS without saving :-( , but also some hardware
> ones. 

Wee, fun ;-)

> I am glad to know that you are working on this project. I meant to 
> form the ideas below more thoroughly before posting them but I see 
> you have already started real work. 

That's probably too generous - I've started trying to become informed
enough to start real work, really.  Bill is probably going to flinch
when he sees my idea of basic pre-code (heck, it's really pure
background) documentation :-).

> So I hope these new suggestions, incomplete as they may be,
> perhaps should be made known to you and we can discuss this 
> and if I got time to revise them (probably during labor day 
> weekend), I'll do so. 

No hurry - you're still far ahead of me when it comes to thinking about
Units/Dimensions in Axiom.  Indeed, you've introduced a new idea I
really like which alters my thinking about basic term definitions that
need to be made and used (more on that later ;-).  I'll reply in parts,
since it's too long for me to have time to sit down and go through at
once.

> It seems that a thorough study of dimensions and units in 
> relation to symbolic computations is not available and your 
> work/paper would be very useful.

I hope so, although I suspect your ideas are far more useful than my
own - I'm just asking questions and swatting user level features around
in my head at this point.  The hard part (and interesting part) is
expressing them in relation to Axiom's mathematical rigor.

> I think we are in general agreement regarding how to implement 
> the UnitSystem domains. Your provoking questions led me to propose 
> modifications to the original scheme (and even that, is far from a 
> final design as I have been changing them constantly as I write). 

Reminds me of working on the Maxima package - I defined several
functions I only realized I would want after I began writing the basic
user documentation.  I think I might still be having conceptual
trainwreaks in my head because of the work on Maxima - some of my
comments below might be a result of this :-/.

> The new scheme hopefully will solve some of the design problems 
> we discussed. I hope before long the new proposal will
> approach a practical one. After waiting a short period of further
> discussions, a summary of the final design should be posted at 
> MathAction for others to comment on. 

Sounds good.  I apologize in advance for how basic some of my questions
below will be - I tried to review as much as possible of earlier
discussions, but I may have regressed some after a rather busy week at
work. 

> I actually prefer your use of ")set UnitSystem ..." to ")set unit
> ...". But note ")set UnitSystem" IS setting the session default for
> the user. Axiom allows a user to set his preferences in a file 
> called axiom.input (which is in the directory $AXIOM/input). 

Off topic, but shouldn't it be checking $HOME/.axiom or some such as
well?  Or is it assumed that a user has write access to $AXIOM?

> So by putting ")set UnitSystem MYUnitSystem" in that file, Axiom 
> will use MYUNitSystem as the default unit system when the 
> functions 'unitMass' etc (to be grouped into a new function
> 'setDim', see below) are called.  MYUnitSystem can be SI, CGS,
> or some modified version of the standard SI (but once modified, 
> it should be called something else). 

This isn't quite what I was thinking - I was thinking by default Axiom
could use a unit system called CurrentUnitSystem, which would be
somewhat different in definition from SI, CGS, etc.  Doing 

)set UnitSystem SI

would drop the user in a strict SI output only environment without the
possibility of local override, which I have no problem with.  (Might
even be a good idea to have available, really - call it a STATIC
UnitSystem definition.)  What i would like CurrentUnitSystem to do is
be a DYNAMIC UnitSystem, using either the system you have outlined
below or something similar.  It would start out as an instance of the
SI definitions by default, but allow local overrides dynamically (hence
a Dynamic UnitSystem definition).  Also useful would be a
SaveUnitSystem(<NewUnitSystemName>) for later use - essentially
allowing a user to load a precustomized Dynamic UnitSystem Definition
as the working UnitSystem.  With a Dynamic UnitSystem Definition we
could have a MapUnitSystem(<UnitSystem name>) command to allow the user
to restore all STATIC SI definitions (say) to the CurrentUnitSystem. 
Is that following what you had in mind?

> Of course, this needs some code or setup to modify the
> interpreter, but it can be done (Tim Daly or Bill Page 
> would no doubt know how and can assist you when that time 
> comes). Most likely, it is a matter of adding one or two 
> lines to a database.

Yes, that's certainly something we will want to do.  (I'm still
plotting to allow the user to gobble up all the unit names in the
default namespace at their option, and that will DEFINITELY need
interpreter work. 

> As for tools to do the dynamic modification from standard unit
> systems like SI, here are several changes to the previous setup 
> that will facilitate this and improve the organization of the 
> domains as well. 

Did you intend to use this setup for ALL UnitSystems or just what I've
termed Dynamic UnitSystems?  (Sorry if I should have caught this.)

[snip - need to ponder some.]

> [Comments: The ideas from now on are more or less well formed.
> However, I have not finished rearranging these in a more logical 
> sequence. So read it a few times! I might have made some obsolete 
> claims as I reorganized my thoughts without revising the claims.]

I'll try :-).

> FIRST: Consolidate all the unitXXX and setUnitXXX functions to::
>
> UnitSystemCategory(S: SetCategory):Category == Exports where
>
>  Dimension ==> Union("Mass", "Length", ...)
>  Unit ==> Union("kg", "m", ...)
>  Join(RetractableTo S,...) with 
>   
>    setDimUnit: (Dimension, Unit, S) -> %
>    setUnit: (Dimension, Unit) -> Null (?)
>    setUnitAll: (Dimension, Unit) -> Null (?)
>
> where 'setDimUnit(dim, unit, s)' is a LOCAL command affecting ONLY 
> s:S, and 'setUnit(dim, unit)' would be a GLOBAL command affecting
> ALL s:S (more on this later).  Null may be replaced with a new 
> state vector?

I don't quite understand s:S - can you give a specific example of this
difference?  Also, I'm not following why you would want to make any
local vs. global distinctions here - wouldn't it be neater just to have
the set commands work in the CurrentUnitSystem, and base things off of
Static UnitSystems for definitions unless a totally custom conversion
is being defined?  Working in a Static UnitSystem no set commands are
either possible or necessary (and thus shouldn't work) and in a Dynamic
UnitSystem (of which there will normally be only one - the working one)
the Static UnitSystems provide the information to use in the Dynamic
one?

I would have thought all you needed was a single command SetUnits()
command, which would take a minimum of one argument and a max of one
unit per available dimension, e.g.

SetUnits(nm,N,inches);

In the CurrentUnitSystem Dynamic UnitSystem (assuming things are in
default mode) the "state vectors" for the dimensions corresponding to
the units entered would be updated.  It's not clear to me why you would
need any other arguments, unless you wanted to make sure the user knows
the dimension of the unit they are inputing as a default.  Dimensions
may not always map uniquely to Units, but Units DO map uniquely to
dimensions.  Couldn't Axiom figure this out?  All it has to do is
determine the dimension of each argument, check that all dimensions are
unique, and set the defaults (the setunits command in Maxima works this
way.)  We ARE back to some parser being able to check all units for a
match to the input unit, I guess. Is that why you're adding the extra
arguments - to avoid Axiom needing to figure out that nm is a Length
defined in the SI UnitSystem?  Maybe I place too much emphasis on user
convenience but I as a user would prefer not to tell Axiom things it
already knows.  Maybe as a time saving alternative SetUnits could also
accept things of the form <UnitSystem>::Unit or some such, which would
limit the search space it would need to check?  Or even better, if
Axiom is up to it we might also be able to build a toplevel hash table
of all defined units in all unit systems at compile time which can
quickly match up a unit up with a UnitSystem and Dimension.  Since
Static UnitSystems wouldn't be changable in a normal session anyway (at
least without editing the source and reloading, which hopefully would
also mandate a rebuild of the hash tree) it would be a one time expense
and would enable considerable user convenience at many levels.  In the
SetUnits usage it doesn't even need to use up toplevel namespace, and
if a user DID want to populate the toplevel namespace it would be a big
speedup for the interperter to be able to hash a symbol to check if it
is a unit.

> Note that the way Dimension and Unit are defined (as Union("Mass",
> "Length",...) and Union("slug", "ft", ...)) is very close to making
> each dimension and unit a domain of its own, except that here each 
> domain consists of just its name(string). You may also consult the 
> way BasicOperators and CommonOperators are designed, but at least 
> for the moment, the simpler setup probably suffices.
>
> SECOND: To support the implementation for 'setUnit' (a dynamical 
> change of units), I propose to add a state vector for each unit 
> system domain: this state vector stores the current unit for each 
> dimension, which is updated by the 'setUnit' command. The
> 'setDimUnit' command can check this state vector before generating
> the Rep (see below). Some care has to be considered: we have to
> decide whether a 'setUnit(dim, unit)' command should affect the
> other derived units that depends on 'dim' or not, and also those 
> the variables whose dimensions were set before this 'setUnit' 
> command and invole 'dim'. I have added 'setUnitAll' for the case 
> every current variable will be updated.

I don't think I'm quite following - Derived Units are defined in terms
of the Base Units for their UnitSystem - just because we are now using
"cm" instead of "m" as our default length doesn't change the definition
of N, or how many Newtons we have.  If we want to report a Derived Unit
in terms of Base Units, then we would want to use cm instead of m, but
otherwise I'm afraid I'm missing something.

As for current variables, shouldn't they be updated automatically by
the global update?

Cheers,
CY


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