Re: [boost] data_binding library for boost... Any interest?

From: Brook Milligan (brook_at_[hidden])
Date: 2008-07-22 16:07:28

Stjepan Rajko writes:
 > I have tried to tackle the value/domain transformation problem a while
 > back, inspired by Brook Milligan's (CC-d) probability library (which
 > can nicely transition probability values between linear and log
 > domains).

 > Brook Milligan also worked on a generic domain transformation library,
 > so he might comment on this as well.  There is also the Boost.Units
 > library which might offer transformations for some cases.

Thanks, Stjepan.  I've continued to refactor that, actually, to make
it support the more generic problem under discussion here.  So far it
is mostly done.  I think the only issues are some silly overloading
resolution issues that have little to do with the basic ideas.  For
the discussion I'll outline my approach.

The basic observation that motivates this is that in some (many?)
situations there exist a group of related types that clearly have
common semantics in the application domain but may impose different
constraints in their implementation.  Indeed, some operations may not
be practical or feasible for some of the types but could be for others
and there may exist transformations from one to another.  In the case
of probabilities think of two types, one for a probability and one for
its logarithm with appropriate operators defined for each domain and
the interconversions.  Another example involves the representation of
polynomials, which can be in terms of coefficients or in spectral
terms that ease their multiplication.  In this case, it may be
completely undesirable to implement a polynomical multiplication for
the coefficient representation.

Conceptually then, the Domain library seeks to create a framework for
implementing sets of such types that work smoothly together, and
enable the compiler to make choices about how to handle mixed domain
operations (e.g., adding a probability and a log probability) or
operations that must be performed in another domain (e.g., multiplying
two polynomials represented as coefficients).  I think these are most
of the salient points, all of which are currently supported.

- Allow definition of families of types (domains) based upon each
  member of a family sharing common semantics in the application
  domain.

- Allow implementation (or not) of any within-domain operators that
  make sense in the application domain.

- Allow implementation (or not) of any appropriate interdomain type
  transformations.

- Decouple the domain type information from the value types used to
  represent the internal domain-specific information.

- Allow specification of a default value type for any domain type so
  that unspecified templates (i.e., T<>) provide meaningful results.

- Allow specification of which domains are interconvertible as a
  series of pairwise conversions.

- Allow specification of which domains support which operations so
  that the compiler can seek an appropriate domain for arguments that
  may (or may not) be directly usable.

The goal is to clearly define all these points of extension so that
the "real" types (e.g., probabilities or polynomials) can be
constructed on top of the Domain library, thereby simplifying the
specification of domain families for any application or library.

I have been using this to refactor the Probability library as a proof
of concept.  As mentioned, most of what the old version could do, the
new one will also do.  There are a few issues with overloads that are
confusing to me, so help is welcome.  Thus, I am certain that there is
some merit in this approach to a generic domain solution.  However, I
am also certain that there are other ideas out there that could
improve this.

Because of the interaction in development between the two libraries
(Domain and Probability) I haven't quite finished everything.  I'll
try to roll them up for viewing shortly, though.

In the meantime, if anyone can help me set up the appropriate bjam
magic for getting quickbook documentation built, including
incorporating doxygen generated information, I'll even improve the
organization for plugging directly into Boost.

I look forward to continuing discussion, receiving input, and
discovering how these ideas might be put to use in other contexts.

Cheers,
Brook