Re: [boost] data_binding

From: Brian Davis (bitminer_at_[hidden])
Date: 2008-07-26 03:20:40

>
>  > The goal I have/desire is to preform type transformations and allow the
>  > programmer to specify these transformations in a generic way
>
> That is more or less the same goal as I have for the Domain library.
> >From what you say below, though, it seems that there may be some
> differences in design or focus.  You seem to focus on what happens
> during an assignment, and want a single assignment to be reflected in
> the value of potentially a number of other variables.
>

Yes that is what I want.  This is what I mean by data binding.  A bunch of
values can be bound together so that when one changes they all change
instead of having set a value to call each conversion function in a chain.

>
> In contrast, I am thinking of what happens when other functions
> (including but not limited to operators) are called.  The idea was to
> allow the user of the Domain library (I envision this person most
> likely being a developer of another domain-specific library) to craft
> the set of type tags, conversion functions, and functions/operators,
> and then have an idiomatic MPL-based means of specifying how they all
> go together.  The job of the Domain library would be to invoke the MPL
> code for domain selection, etc. so that the user of the library would
> not have to worry about this and even more so, so that the user of
> that library would never have to worry about domain transformations
> when they call the functions/operators but could rely on domain
> correctness, even in completely generic algorithms.
>

Users of the libraries often become the extenders of the library when
ultimately it does not meet there needs.  All libs suffer from this.  So
making it extensible is important to allow the user to extend it to their
domain.  This library is then a library for library developers for domain
specific transformations?

>
> I will give more thought to rolling the assignment operator into this,
> but I'm not sure yet how the two ideas fit together.
>

Give the demo code a try if you haven't... Either you will be aghast by what
I have done or find it a very nifty bit of code.  I guess there will be very
little middle ground for those who see how it works.

>  > Yes so some types can not be automatically transformed.  My example
> provides
>  > absolutely no support for this except for 1 to 1 translation... for
>  > disparate types it is... well... compiler errors waiting to happen if no
>  > translation functions are supplied.
>
>
> You mention the possibility of a 1:1 transformation.  In my context,
> I'm not certain what that means.  To me that signifies two different
> types in the same domain.  Those can only be differentiated with
> respect to their value types (i.e., the types actually holding the
> data as opposed to the parts that track the domain information).  In
> my scheme, as long as one value type can be constructed from another,
> there is always such a transformation within the same domain.  No need
> for special support.  Did you have something else in mind?
>

What I mean by 1 to 1 is that if no transformation functions are specified a
values A set and bound to value B will be equal 1:1.  If you set A to 1 B
will be 1 if you set B to 45 A will be 45.  What I mean by compiler errors
waiting to happen is that there is not type checking for primitive types (it
is as was only a simple example of what I had in mind.) so if you pass in T1
= float and a class for T2 without transformation functions you will get
compiler warnings when you set A to 2.34 ... what does the class B equal?
... compiler errors.

>
> It will always be the case that certain operations make no sense for
> certain domains.  Thus, it is possible to try to use expressions on
> the generic domain types that cannot be resolved by the appropriate
> template specializations.  I see this as no different from trying to
> use any ill-defined expression, though.  The compiler will catch it,
> you will pay more attention to the documentation that describes what
> is legal for that domain, and you will fix your code.  What else is
> possible?
>

That seems perfectly reasonable and correct.

>
>  > The software engineer shall be allowed to specify a transform is the
>  > compiler cannot automatically figure it out.
>
> More precisely, the engineer must specify a transformation between
> domains that must be interconverted.  Except for the trivial case of
> transforming between value types within a domain, which is really not
> a domain transformation at all, the compiler cannot possibly know what
> transformation is appropriate.
>
> The goal here is to make it easier for an engineer to construct a
> library appropriate to a particular set of domains (an application
> domain if you will) so that the users of his/her library in turn have
> a truly easy set of generic, but domain-aware, operations to work
> with.
>
>  > How difficult is it to specify new types and tranforms.... Are we
> talking
>  > about the types like thoes defined by the section titled "A Deeper Look
> at
>  > Meatafunctions - 3.1 Dimensional Analysis" in "C++ Template
> Metaprogramming"
>  > by David and Aleksey?  If so ... ouch... could be quite painful to
> specify
>  > new types and conversions... What is your approach?
>
> Developing a domain-aware library based upon the Domain library
> essentially involves the following:
>
> - Naming the set of domains and the individual domains within the set.
>  This is only a matter of creating a set of tags for dispatching;
>  essentially this is an organized set of empty structures to create
>  convenient names that guide template specialization.
>
> - Potentially, creating an appropriate set of value types to hold
>  whatever information is needed.  In many cases, these will be
>  preexisting types; in others, they will need special construction.
>  As always, it all depends on the application domain.
>
> - Creating the domain transformation functions.  These are a set of
>  specializations of template functions within a defined namespace.
>
> - Potentially creating any appropriate definitions for operators.
>  These are a set of specializations of classes within a defined
>  namespace.
>
> - Potentially creating non-operator functions on the domain types.
>  Since these cannot be known in advance (unlike the operators), a bit
>  more work is required on the part of the user of the Domain
>  library.  However, this is largely idiomatic and easily supported
>  within the framework.
>
> - Identifying which domain transformations are available.  This
>  involves a specialization of a single class within a defined
>  namespace.
>
> - Identifying which domains are appropriate for which operations.  For
>  example, additive operations may be defined for all domains, but
>  multiplicative ones defined only for some.  This is handled by a set
>  of simple MPL vectors of domains.  The library takes care of sorting
>  through the domains of function arguments, the set of domain
>  interconversions, and the domains that are appropriate for the
>  called operation to find an appropriate domain.  The arguments are
>  converted to the target domain if necessary before the operation is
>  performed.  This is perhaps the main thing that makes the library
>  useful, as this makes the operations generic while maintaining
>  domain-correctness.
>
>  > Yes sounds great with the exception of the "operators portion"... like
> every
>  > one in boost using operators for new purposes (think Spirit - and I
> don't
>  > mean this in a bad way) we are running out of operators which provide
>  > meaningful schematics...
>
> I am thinking of cases in which the operators already have a natural
> meaning in the application domain being modeled by all the domain
> types, but that the implementations might differ among domain types
> and so interconversions are required.  This is quite different than
> overloading operators to describe an entirely new language, as Spirit
> does.

Let me just clarify what I mean here.

Consider Matrix calculations where it would be nice to be able to use
operators standard to the domain where you have

X =
        { 1 }
        { 2 }
        { 3 |

As a column vector

It would be great to type in c++

X' and get {1 2 3 } the row vector, but alas we cannot type this in C++, but
we might be able to if we had access to other operators which look like this
because we would be writing code in a Unicode editor with a complier that
supports Unicode text and has been expanded to utilize the new operators
that using such a coding scheme would provide.  I would not see backward
compatibility issues here as if you are using a Unicode Editor you are
writing forward compatible code.  Have you ever been writing code only to
find that you wish the syntax you desire was possible, but you are limited
by the limited set of operators by which to overload.  They can speak to it,
but I am sure the Spirit and Karma guys might agree with me here.   This
however is a off topic for this and a little too forward thinking.  Sadly I
feel we have been crippled as developers by standards based on UTF8 encoding
:-(  Lets free our compilers and free our code... Unicode ... Who's with me!
... I'll digress again...

>
>  > What happens when and operation cannot be found in a domain, but the
>  > programmer can or needs to specify one?  Is it extensible?
>
> Yes, generally by specializing things in well-known namespaces.
>
>  > The easier it is to provide new specifications for types and their
>  > transformations the better.... you'll never think of every domain and
>  > translation.  Need to supply a clear path to adding new types, domains,
> and
>  > translations.
>
> Of course.  The goal is to make it easy and idiomatic for others to do
> this, not to anticipate all possible uses.  As I mentioned, the role
> of this is as a base layer upon which application domain-specific
> libraries are easy to build.
>
>  > How do I obtain the code and where is the problem?
>
> I'll try to get it in shape for public consumption this weekend.  I
> have a worked example based on a toy polynomial library to illustrate
> how to build a library on top of the Domain library.  However, the
> documentation is mainly in the form of Doxygen comments and so I need
> to give a bit more of the overview.  Stay tuned. ...
>

I am familiar with running Doxygen and bjam.  Can't say I am an expert in
either, but I can find my way around with these tools.  I am interested to
see what you've got.  It sounds like you have given this a considerable
amount more thought that I.

>
>  > Gerneric domain is exactly what I am after.  We have type T1, T2,
> T3,....TN
>  > and we have to translate between them... What's the easiest way to
> specify
>  > this for the programmer?
>
> That and how to automate the process of choosing the transformations
> is what I'm trying to make easy.  As soon as I can get the code out
> there, please let me know how to improve the ideas.
>
> Thanks alot for your interest so far.  I look forward to additional
> comments.
>

Out of curiosity do you think this library could support time domain
transforms to Z-transforms and  S-transforms.  How complex a transformation
do you think it will support?

I help where I can. Provide input where I can and hope it helps.

Brian