Boost logo

Boost :

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at