
Ublas : 
From: Michael Stevens (mail_at_[hidden])
Date: 20061212 14:19:39
On Saturday, 2. December 2006 19:20, Manoj Rajagopalan wrote:
> Thanks Michael! So this is how I have understood the closure concept.
> Correct me if I am wrong:
>
> A closure is the generalization of a reference to include functions and
> the arguments that a function call is bound to at the time the call is
> made. This is possible only when functions are firstclass objects,
> i.e., they can be passed around just like variables can. For example, if
> a function that computes sin(ax) is declared as double sin(double a,
> double x), and we'd like to construct a reference to this sin function
> for a particular value of 'a' and pass that to something like a graphing
> function, then such a reference that includes the reference to an
> argument as well as to the function would be called a closure. The
> origin of this term is from functional programming where it is possible
> to construct such (partial) bindings and pass them around to other
> functions.
That is precisely my understanding. The expression template mechanism in uBLAS
attempts to build first class objects. At some point later we expect these to
be passed to an assignment function which then accesses the expression via
its iterator and 'find' interfaces.
>
> In uBLAS, expression templates are used to construct scalarexpressions,
> vectorexpressions and matrixexpressions so that they can be
> efficiently evaluated.
Careful with scalarexpressions. They are disable in uBLAS at the moment due
to implementation problems. At present the expression
M * sum(M)
evalutes sum(M) at the point where it is instantiated rather then creating
closure using 'vector_scalar_unary_traits'. It would be interesting to look
again with modern compilers to see if this code can be corrected or if the
problem is inherent in the design.
> An expression encapsulating a binary operation
> like addition must refer to the addition operation and to the two
> operands being added. When addition operations occur at multiple places
> in the code with different operands (which may themselves be
> expressions), then each occurrence is encapsulated in a closure, i.e., a
> reference to the same addition operation but different operandpair. Two
> such closures are identical if and only if they refer to the same
> operation on the same set of operands.
We don't really need to define when closures are identical, but it is an
interesting point Probably a more useful definition would be based on operand
TYPE rather then instance. I would make the destinction because the
expressions (closures) are types.
For example:
vector<float> a,b;
a + a;
b + a;
b + b;
a + b;
Creates four identical expression closures because all four result in the
identical template type instantiations.
Michael
 ___________________________________ Michael Stevens Systems Engineering 34128 Kassel, Germany Phone/Fax: +49 561 5218038 Navigation Systems, Estimation and Bayesian Filtering http://bayesclasses.sf.net ___________________________________