Re: Extended unit

Martijn van Oosterhout <kleptog(at)svana(dot)org> writes:

> Now, how to store the relationships between them to handle
> multiplication and division. Probably go back to base types...

I've thought about this myself quite a bit. I decided that trying to implement
multiplication and division is a bad idea.

What you really want is just a type that guarantees that you can add and
subtract two dimensional values as long as they're in the same units.
(1km + 2km = 3km)

You should also be able to divide two dimensional values of the same type and
get a plain dimensionless floating point number. (2km / 1km = 2.0)

Also you should be able to multiple or divide a dimensional value with a
dimensionless value. (2km * 2.0 = 4km)

All of the above doesn't require recognizing what the meaning of the
dimensions are at all. As long as they're all linear they can be completely
opaque strings. That keeps the system quite simple.

It also keeps it most flexible in that a user can use *any* unit whatsoever.
Not just units from some approved list.

If you wanted to implement multiplying two dimensioned values or converting
from one unit to another then you would suddenly have to know the meaning of
every unit.

You could implement the sementic-free approach where the system doesn't know
anything about the actual meanings of units and then implement a function that
allows you to call out to the traditional units program to convert.

So you could have units_conv(dim_val, 'km') to call units and request to
convert whatever is in the dim_val column into km. And maybe a
units_expr(dim_val||'*'||dim_val2, 'km^2').

I would suggest this because it doesn't try to reimplement all of units and it
isolates the complex parts that limit the flexibility of the system in one
area. Someone who isn't trying to use postgres as a units substitute doesn't
have to deal with it.

--
greg