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