[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Axiom-developer] Unit package question
From: |
Ralf Hemmecke |
Subject: |
Re: [Axiom-developer] Unit package question |
Date: |
Tue, 23 Aug 2005 16:44:22 +0200 |
User-agent: |
Mozilla Thunderbird 1.0 (X11/20041206) |
Hello Clifford,
Since I have more Aldor background, I would rather suggest to write the
package as an Aldor library building on libaxiom.al. Maybe you could
even write your code in such an abstract way that it would also compile
against libaldor. That would be great. What I see at the moment is that
you only need multiplication, division and addition or rather partial
addition
+: (%, %) -> Partial % (in Aldor terms)
Union(%, failed) in terms of Axiom (I believe). So the resulting
domain is not a field.
I would opt of _one_ Unit domain that internally stores the different
units in terms of "pivot" units.
> Furthermore, you use
> U == Fraction Polynomial Integer
> as an internal domain and yet do something with it
> withUnits: (R, U) -> %
> :-( OK, I know your code is just a draft. Sorry.
> But I would NEVER export the internal units domain.
Of course not. It was only a draft.
Frighteningly, I don't know why this is obvious. Where do I find out
why it's obvious?
You certainly know of "information hiding" why would you let a user of
the Units domain want to know its internal representation? Would you as
a _user_ of the Float domain like to know its internal structure. No.
The only thing that is needed is the API, the properties that this
domain has. That is why I said that U should not be seen outside of the
Units domain.
> I would rather internally represent the domain as
> Fraction DMP(SIbasics, R)
> where SIbasics is something like
> [kg, s, m, A, K,...]
> and put into the exports all the various units, for example,
> g: % -- gramm
> h: % -- hour
> N: % -- Newton
> etc.
> Internally everything is represented in base units.
I think this is unnecessary, I'd simply store the appropriate unit
and convert only if conversion is necessary, be it because two
elements of different unit are added, be it that the user asks for
it.
I agree, but the conversion information itself must be stored, and THAT
information should be encoded internally in terms of some one unit on a
per-domain basis - it simplifies life tremendously. I call that the
pivot unit.
As you see below. The implementation of the constant g would be
g: % == 1/1000 * kg
> When it comes to printing (coercion to OutputForm) then the
internal units
> are transformed into the desired units. So one might transform
kg*m/s^2 into
> printing N instead.
Ah, that's maybe a different story. I was talking about keeping
centimeters as centimeters...
I only want to keep centimeters as centimeters if the "global" length
unit is set as centimeters, at least in my design. One of the reasons
to have units in a CAS is to do autoconversion to the units you want.
Hmmm, I still would store internally the units as kg, s, m, etc. If you
really like auto conversion to the units you are interested in than you
would have to make the Units domain to carry a state. Something like,
Units(...): ... == add {
outputUnits: HashTable(String, String) == ["kg", "m", ... ];
setOutputUnit(length, "cm"): String == ...
...
}
(I think String is a bad choice here, but I cannot think of something
better at the moement.)
> Hmmm, I just see that my suggestion of Fraction DMP(SIbasics, R)
> is stupid. One never wants as a result something like 4*m+5*A. I
> cannot imaging that this would be useful.
Yes, but it doesn't really matter. AlgebraicNumbers are stored as
Expression Integer...
Actually, it does matter - Axiom should prevent such an expression from
being legal at all. If it occurs anywhere, it's an error.
... or it should return a "failed" value see the +: (%, %) -> Partial %
suggestion at the beginning.
Where's the DMP code? Is it well documented?
Maybe you browse with hyperdoc for DMP. But what I actually meant was,
that something like a DirectProduct or an Array would do for the
implementation of the pivot units. Each unit gets a slot and you store
the corresponding exponent of the unit in that slot. In fact, a good
implementation of Z^n as a monoid is what you want, maybe
Vector(Integer) works.
Can it happen that the ratio of two units is irrational?
Irrational as in an irrational number or irrational as in nonsensical
or nonphysical? I can't think of a case off hand where this would be
nonphysical, but that doesn't mean there isn't one. However, until
proven otherwise, I think the assumption that multiplication and
division of dimensional quantities is always legal is the correct one
to proceed on.
Theoretically the ratio could be an irrational number, but any number
written out in decimal form that I have ever seen in my life was
rational. Maybe there is someone who knows of two units that are in
irrational correspondence. What about a \pi meter?
Ralf
- Re: [Axiom-developer] Unit package question,
Ralf Hemmecke <=