[boost] Re: runtime unit-modifiablephysical-quantitiesusingpqs1-00-01

From: Dan W. (danw_at_[hidden])
Date: 2004-01-06 22:03:10

Sorry, I hadn't noticed your message..

J.F.K. wrote:

>> Ahhh! Yup, this is a conondrum; because I don't want to mix apples and 
>> bananas, and if I do I can cast them to fruits; but how does one 
>> prevent zero-power-units types from inter-converting? How about 
>> treating them specially? For all non-zero power dimension types, 
>> conversions could be template-instantiated as required; but zero power 
>> ones are typed as per the name the user gives them, and if two names 
>> don't match you need a cast or explicit conversion. Could this work? 
>> This could prevent taking the arc-cosine of Federal tax by accident.
> stop here, please!
> scalar is scalar, one could have an ability to write:
> f = l1/l2 + v1/v2;
> where l1 and l2 are lengths, v1 and v2 are velocities, and f is a scalar 
> of cause.

Right, I wasn't thinking. Apples would be a unit, and bananas would be 
another unit;  so these aren't scalars to begin with.

> The idea was already arised in this thread:
> if "Federal tax" is imortant entity in your program - you could declare 
> special dimention for it, and IMO it is a convinient way to
>> prevent taking the arc-cosine of Federal tax by accident.

Right.  Even percentages don't need to be scalars, we could have a
rain_tomorrow_probability_percent
democrat_next_term_probability_percent
Federal_Sales_Tax_percent
and so on, so we don't add them together.

> preferred usage of units library for me:
> * declare dimensions that'll be used in the program (Federal tax, e.t.c.)
> * write my program :)

I'm with ya.  The more I think about it, the more it seems to me that 
the whole concept of "dimension" doesn't have one point of contact with 
the problem domain.  All one needs is the units.  Of what, it doesn't 
matter, really;  as long as we have ways to convert between units.

Cheers!