Re: Extended unit

On Jan 26, 2005, at 20:06, Pailloncy Jean-Gerard wrote:

>>> It strikes me that the right level of constraint is the quantity
>>> being
>>> represented: length / mass / time / velocity.
>>>
>>> Then you could store any of: '1inch', '2m', '3km', '4light-years' in
>>> a
>>> "length" column.
>>
>> Ofcourse, only one of those is in SI units :) Just like the interval
>> type, all this could be handled by the parser. Define some costant
>> conversions, after all a light-year is about 9.5e15 metres.
>>
>> The question is, if you put one inch in, do you expect to get one inch
>> out?
> I'm glad that some understand that I want to have strong type checking
> and not multiform filed (with special compound type).
>
> I want that whater is the unit in, the data is coherent.
> And the output will be format with convert function.

<snip />

> I am in the process of writing such function to convert from test to
> an internal format.
> But the problem is that all the work I am doing is about coupound type
> (double, unit)
> the unit type is an integer with for table for the definition of unit,
> convertion and translation in human form.

This reminds me of Date and Darwen's possible representations. You
might be interested in some of their writings, in particular "The Third
Manifesto", though they have some papers online as well. Most of what
they discuss is at a more theoretical level rather than implementation,
but it provides some food for thought. Here's a couple of sites. The
second is also includes writings by Fabien Pascal.

http://www.thethirdmanifesto.com/
http://www.dbdebunk.com/index.html

Neat stuff, in my opinion.

Michael Glaesemann
grzm myrealbox com