Re: [boost] Re: physical-quantities (was: runtime unit-modifiable ...)

From: Matthias Schabel (boost_at_[hidden])
Date: 2004-01-07 19:15:31

> so i think this is not going to work like i tried it. want is really  
> needed is an associative container in the mpl. we both just tried to  
> emulate one. the vector is fast but too inflexible and your list  
> approach works fine but is too inefficient.

Exactly - for arbitrary tag types, you really just need a set container  
since order of the various tags is irrelevant.  also, if there was some  
way to specify the compile time sorting criterion so that all duplicate  
tags were guaranteed to be adjacent, that would enable me to eliminate  
one order of N in the algorithms off the bat.  What I mean is, say  
we're doing dimensional analysis with some tags :

struct tag1 { };
struct tag2 { };

if it was guaranteed that iterating through

mpl::set<dim<tag1,1>,dim<tag2,-1>,dim<tag1,2> >

could be defined by sorting on some unique integer type identifier  
derived from the tags tag1 and tag2 so that all terms containing tag1  
appeared adjacent sequentially, then collapsing duplicates in the set  
could be made much more efficient.

> yes, but i had not enough time to look really into the details. and it  
> was difficult because you never know from the code what are the  
> implementational details, what is the real usage and what is  
> syntactical sugar. eg, i thought from looking at andys examples, that  
> the value_type in his lib is always double.

I guess I'd consider the stuff that appears in the test programs to be  
interface and the headers to be primarily implementation, but I'm not  
completely wedded to particular details of the former, particularly  
with regard to the units superstructure.

> what i also like about your library is the use of namespaces and the  
> fact that dimensions are specialized for physics and the unit systems  
> like si, usw. use them together (i dont know how andy does this).  
> although the special definitions and namings might need some more work  
> towards the end.

Thanks - I've been trying to address all (reasonable) issues that were  
raised regarding prior incarnations.  The fixed dimension list approach  
is ancient history and has not been accepted precisely because it lacks  
the flexibility to address the broad problem space that dimensional  
analysis/units are going to be called on to address.  For example, as a  
physicist, I would expect that (N m) torque and J _would_ be  
interchangeable, but can also see how in the mechanical engineering  
domain that might be undesirable and (newton_meters) might be a  
reasonable basis unit.  Of course, it is ultimately up to the domain  
experts to define domain appropriate unit systems.  I'm just hoping to  
come up with a system which is sufficiently flexible to accommodate as  
many reasonable possibilities as possible.

------------------------------------------------------------------------ 
---------------------------
Matthias Schabel, Ph.D.                           	
Utah Center for Advanced Imaging Research
729 Arapeen Drive
Salt Lake City, UT  84108
801-587-9413 (work)
801-585-3592 (fax)
801-706-5760 (cell)
801-484-0811 (home)
mschabel at ucair med utah edu