Glas List: Re: [glas] mapping expressions to backend

From: Andreas Pokorny (andreas.pokorny_at_[hidden])
Date: 2006-01-18 12:53:48

On Wed, Jan 18, 2006 at 01:11:09PM +0100, Toon Knapen <toon.knapen_at_[hidden]> wrote:
> Andreas Pokorny wrote:
> > 
> > You could have both, you could attach the info about the backend to your
> > types. And you could have a kind of override syntax in your expressions. 
> > So for every backend a small backend tag type, and an instance of each
> > of them.
> > 
> > struct glas_lib_tag {};
> > struct atlas_lib_tag {};
> > struct example_library_tag {};
> > 
> > const glas_tag glas_lib;
> > const atlas_tag atlas_lib;
> > const example_library_tag example_library;
> > 
> > is required. These tags then can be attached to types. E.g: 
> > 
> >   matrix<float,atlas_lib_tag> mat;
> 
> 
> Great. Currently we have provided this functionality already (but we
> always used the term 'attribute' instead of 'tag').

Yes, i just saw that. In my clean rewrite I do use boost::fusion-2 maps 
to store meta information like that inside of expressions. And containers 
are value expression in the terms of the frontend, so these also carry
attributes. 

> 
> >   matrix<float> some_other_matrix; // glas_lib_tag could be the default
> > 
> >   mat *= some_other_matrix; 
> > 
> > and this expression will be evaluated using atlas. 
> 
> 
> Indeed, here you could say that the expression needs to be evaluated
> using atlas because one container clearly preferred atlas while the
> other had no preference. The situation can easily get ambiguous for
> instance like in the following
> 
> 
> matrix<float,some_other_backend_tag> mat_other ;
> mat_other *= mat
> 
> 
> What backend should be used now: atlas or the 'other_backend'?
> This ambiguity is a consequence of attaching the attribute describing
> the preferred-backend to the container instead of the operation. Because
> it's actually the operation/expression that needs to be mapped to a
> backend. Attaching an attribute to an operator however is syntactically
> very difficult and thus resolving in option 2 (unless you have a better
> idea) in my initial mail.

In my case the left side of the assignment operator defines what backend
has to be used. In fact attaching the backend information to a type was a
feature not planed at the beginning. So the default was always basic_system,
if no other was given using the []-syntax. So the general rule for
picking the backend is always: let the left side of the assignment
decide. 

One could also gather all backend info used inside of one expression and
store that in a type sequence while processing towards the '='. Then
one could ask some meta function which backend dominates the others. 
But I think thats not verbose enough for the user to understand, what
backend is used. 

That leads me to the possibility of combining backends. Which is
currently not yet supported by my code, but possible provided that all
backends follow the structure imposed by basic_system. 

The current default backend defines a set of node structures, for all
kinds of binary and unary nodes in a linear algebra expressions. Each
of them has at least an operator() to evaluate the given node type. 
These nodes are assembled during the different assignment operators.

Currently a depth-first search using the backend tag is done to find 
the most specific partial or full specialization of a requested node 
types. I think it would be possible to replace the depth search with 
a breadth-first search, using all given backend tags. The syntax
proposed by Dave Abrahams will then look like that: 

 mat[some_lib,another_feature,atlas_lib] += a*t; 

> 
> > And to override that
> > setting, the user could write:
> >    
> >   mat[example_library] *= some_other_matrix; 
> > 
> > and a different implementation will be used.
> 
> 
> This is indeed another alternative for the possible syntaxes I described
> for option 2. I'm not sure which syntax is the easiest and clearest.

I cannot tell either, I am already biassed by my solution :).

Regards
Andreas Pokorny