RE: [boost] spatial and metric containers

From: Reid Sweatman (drunkardswalk_at_[hidden])
Date: 2003-07-27 19:38:41

> -----Original Message-----
> From: boost-bounces_at_[hidden]
> [mailto:boost-bounces_at_[hidden]]On Behalf Of conrado_at_[hidden]
> Sent: Thursday, July 24, 2003 7:59 AM
> To: boost_at_[hidden]
> Subject: [boost] spatial and metric containers

<snipped>

> An spatial container template accepts a dimension d, a key type
> and a mapped type. The key type can be anything as long
> as it behaves as a d-dimensional tuple where for each attribute there
> is some total order. The necessary flexibility is achieved through a

<snipped>

> A metric container template accepts a key type T, a mapped type and a
> metric functor. A metric functor for type T
> must provide double operator()(const T&, const T&), to measure the
> distance between two T's. As a metric the distance function d
> must satisfy d(x,x)=0,
> d(x,y) = d(y,x), d(x,y)>0 if x!=y, and d(x,y) <= d(x,z)+d(z,y)
> (triangular inequality). The

<snipped>

Personally, I'd be interested.  Small semiotic quibble, though, concerning
the name, and possibly, the organizational scheme.  Spatial measurements
are, by definition, metric, so the terminology is redundant.  It looks more
like the distinction (beyond the difference in data structures) is one of
tensor rank.  And once I start thinking of it that way, I also start to
wonder whether it might not be better to rename it to better reflect the
problem domain, and perhaps, reorganize it that way.    Maybe this is all
just a meaningless cavil, but I'm sort of looking for a more generalized
version of what was obviously intended to solve problems in a particular
domain.  The confusion over semantics makes me wonder about the
organization, is all.

A metric is a pretty specific sort of tensor, and a distance yet another.
First, it seems that your metric containers should take spatial containers
as arguments and return values, if the terminology is to be consistent.  I'm
not trying to argue that you should make some kind of specialized tensor
library (although it really would be, that's hardly the point), but I do
wonder whether the existing libraries in that direction in Boost might not
provide the basis for a specialization into this problem domain.  I haven't
put any real thought into it, but maybe this would work as adapters on
existing structures.

I hope this doesn't come off as tiresome and pedantic, although it reads
that way even to me <g>.  I just got a sense that as constituted, your code
was unwittingly working with apples and oranges.  Correct me if I'm wrong,
but it really feels like the two containers are a scalar data type (ignoring
the attached associative data structures) and a metric (or "distance"
function).  "Metric" is already a much more generic term than "distance" or
even "spatial," although related.  I don't have a problem with the word
"metric," (although I suspect it's a term more familiar to physicists or
topologists than to programmers), but I'm damned if I can think of a good,
simple term for the first data type.  "Distance" is certainly one
possibility, although it carries a lot of denotative freight that most
programmers wouldn't be aware of; it has common meaning, which wouldn't
cover all the uses of this data object, and yet is really a pretty abstract
topological concept (again, as is "metric").  Anything mensurable can have a
metric associated with it; what then, do you call the "distance" the metric
is measuring?  Especially if it isn't a "distance" in the conventional
sense?

If this seems really off-base, just tell me to shut up and I'll return to
lurk-mode.  I would hope, though, that it might spark useful comments from
someone here who's thinking a bit more deeply than I.

Reid Sweatman