Re: SIunits and quantity library concerns

From: Eric Ford (eford_at_[hidden])
Date: 2001-10-04 21:23:49

> I like the idea of using the name "tag" for a user defined quantity.
> I also like Kevin's idea of phrase "isa" questions by asking how
they
> could be used in a calculation.  Basically Kevin is reminding us
that
> we should be using the LSP (Liskov Substitutability Principle,
> http://ootips.org/lsp.html) to make our programming decisions NOT
> philosophy!  The LSP says that if you can substitute one type A for
> type B then A should inherit from B.  So a "Kg of apples" is a
> reasonable thing to pass into any function that wants a "kg of
fruit".
> Thus, we want to think of it as inheriting from a "kg of fruit." 
This
> answers all the nice questions proposed by Kevin Lynch the exact
same
> way he answered them.

I also found Kevin's post sensible.  However, I don't think the only
way to interpret his post is terms of inheritance.  I think his ideas
would also be realized by allowing users to specialize operations. 
Further, I beleive specialization allows the user more control over
exactly how their units and unit qualifiers are handeled.  (I'm not an
expert but I beleive LSP was around before generic programming was
worth noticing.)

Sometimes users may want to say number_of_apples can be converted unto
number_of_fruits.  Other times a user may not want that to be allowed,
but still allow addition of number_of_apples and number_of_oranges to
equal number_of_fruits.  

Multiplications and divisions are even more complex.  A user might
want an inverse weight (number_of_apples_per_pound) times a weight
(pounds_of_apples) to go to a pure number (number_of_apples), where
the qualifier stays around.  Other times a user might want something
like pounds_of_apples_per_pounds_of_oranges times pounds_of_oranges to
go to pounds_of_apples, where the qualifier disappears.  

Specialization allows users to specify exactly when they want the
qualifiers to stick around, when they want them to disappear, and when
they want something else.  I think that would be more difficult with
inheritance.

BTW- You may want to look at my qualified_unit upload.  It lets a unit
library deal with converting units and the user allow with the
qualifiers.  By default addition and subtraction require the units be
addable/substractable and the qualifiers be an exact match.  It deals
with the multiplication and division problem by having the deault
behaving be to build a tree of the the qualifiers.  

Of course, the user can specialize this for some or all of their
qualifiers and/or qualified units.  :)

Currently, there is the problem is that qualified units made by
multiplying and dividing the same qualified units but in a different
order will result in trees that appears to be different.  This is the
problem that any node can be considered to be the root node.  It's
also made more difficult by the fact that 1/(1/x)==x.  Maybe someone
who actually took CS courses knows a good way to identify equivalent
trees and deal with this quirk.  Alternatively, maybe there's a better
data structure for the aggregation of qualifiers.  

E