Re: [proto] Defining the result domain of a proto operator
Le 26/08/2011 17:56, Eric Niebler a écrit :
On 8/26/2011 11:44 AM, Eric Niebler wrote:
Proto will
compute the domain of m*v to be matrix. It will use matrix_domain's
generator to post-process the new expression. That generator can do
anything -- including placing the new expression in the vector domain.
In short, there is no requirement that a domain's generator must produce
expressions in that domain. Just hack matrix_domain's generator.
Expanding on this a bit ... there doesn't seem to a sub-/super-domain
relationship between matrix and vector. Why not make them both (together
with covector) sub-domains of some abstract nt2_domain, which has all
the logic for deciding which sub-domain a particular expression should
be in based on its structure? Its generator could actually be a Proto
algorithm, like:
nt2_generator
: proto::or_<
proto::when<
vector_grammar
, proto::generator(_)>
proto::when<
covector_grammar
, proto::generator(_)>
proto::otherwise<
proto::generator(_)>
>
{};
struct nt2_domain
: proto::domain
{};
Etc...
I think you hit it right on the spot. I'll see how to make this
consistent with table and other stuff.
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] Defining the result domain of a proto operator
Le 26/08/2011 17:44, Eric Niebler a écrit :
On 8/26/2011 11:23 AM, Joel Falcou wrote:
On 26/08/2011 17:18, Eric Niebler wrote:
Why can't you use a grammar to recognize patterns like these and
take appropriate action?
we do. Another point is that container based operation in our system
need to know the number of dimension of the container. Domains carry
this dimensions informations as we dont want to mix different sized
container in a same expression. The containers we have are :
table which can have 1 to MAX_DIM dimesnions matrix which behave as
table<2> when mixed with table covector and vector that act as a
matrix when mixed with matrix adn table<2> with table.
The domain are then flagged with this dimension informations.
OK, then I'll just assume you guys know what you're doing ('cause you
clearly do).
Except ... read after that
The answer is no, but you don't need that, I don't think. Proto will
compute the domain of m*v to be matrix. It will use matrix_domain's
generator to post-process the new expression. That generator can do
anything -- including placing the new expression in the vector domain.
In short, there is no requirement that a domain's generator must produce
expressions in that domain. Just hack matrix_domain's generator.
OK, if we can do that, in fact, we can remove the meta_informations from
the domain all together and just have table_domain and
matrix/vector/covector_domain then use a hacked geenrator to do all the
checking/recreation we need. I guess we can handle the checking on size,
gemm/gemv proper sytsem in the generator and allow m * v in matrix
grammar etc ... And this hacked generator can static_assert proper
message when uncomaptible stuff get mixed.
Again seems proto lack of some obscure feature I thought necessary makes
my problem clearer. Put this on hold then, I'll try to come up with a
better implementation of my domain handling.
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] Defining the result domain of a proto operator
On 8/26/2011 11:31 AM, Joel Falcou wrote: These coudl be grammar. Anytime you want to have somethign selecting somethign based on expression structure, it is a grammar. Such metafonction systems ar eusualyl brittle or not extensible enough. Originally I did have more of this tied into grammar, but I found the compile times to be very slow. Moving to this structure eased that, and I've found the result to be fairly easy to extend. What exactly is brittle about it? ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] Defining the result domain of a proto operator
On 8/26/2011 11:44 AM, Eric Niebler wrote:
> Proto will
> compute the domain of m*v to be matrix. It will use matrix_domain's
> generator to post-process the new expression. That generator can do
> anything -- including placing the new expression in the vector domain.
> In short, there is no requirement that a domain's generator must produce
> expressions in that domain. Just hack matrix_domain's generator.
Expanding on this a bit ... there doesn't seem to a sub-/super-domain
relationship between matrix and vector. Why not make them both (together
with covector) sub-domains of some abstract nt2_domain, which has all
the logic for deciding which sub-domain a particular expression should
be in based on its structure? Its generator could actually be a Proto
algorithm, like:
nt2_generator
: proto::or_<
proto::when<
vector_grammar
, proto::generator(_)>
proto::when<
covector_grammar
, proto::generator(_)>
proto::otherwise<
proto::generator(_)>
>
{};
struct nt2_domain
: proto::domain
{};
Etc...
--
Eric Niebler
BoostPro Computing
http://www.boostpro.com
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] Defining the result domain of a proto operator
On 8/26/2011 11:23 AM, Joel Falcou wrote:
> On 26/08/2011 17:18, Eric Niebler wrote:
>> Why can't you use a grammar to recognize patterns like these and
>> take appropriate action?
>
> we do. Another point is that container based operation in our system
> need to know the number of dimension of the container. Domains carry
> this dimensions informations as we dont want to mix different sized
> container in a same expression. The containers we have are :
>
> table which can have 1 to MAX_DIM dimesnions matrix which behave as
> table<2> when mixed with table covector and vector that act as a
> matrix when mixed with matrix adn table<2> with table.
>
> The domain are then flagged with this dimension informations.
OK, then I'll just assume you guys know what you're doing ('cause you
clearly do).
The original questions was:
> Is there a mechanism in Proto to define how the domain of a node new
> should be computed depending on the tag and the domains of the
> children?
The answer is no, but you don't need that, I don't think. Proto will
compute the domain of m*v to be matrix. It will use matrix_domain's
generator to post-process the new expression. That generator can do
anything -- including placing the new expression in the vector domain.
In short, there is no requirement that a domain's generator must produce
expressions in that domain. Just hack matrix_domain's generator.
--
Eric Niebler
BoostPro Computing
http://www.boostpro.com
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] Defining the result domain of a proto operator
On 26/08/2011 17:27, Brandon Kohn wrote: I solved this kind of problem by tagging the various types in traits structs and then embedding these traits in the transforms for the various operations. Here are examples of my expression, grammar, and binary function definitions: https://github.com/brandon-kohn/Geometrix/blob/master/geometrix/algebra/expression.hpp https://github.com/brandon-kohn/Geometrix/blob/master/geometrix/algebra/grammar.hpp https://github.com/brandon-kohn/Geometrix/blob/master/geometrix/algebra/binary_functions.hpp I'm not sure if this is the best way to do these, but it does work. These coudl be grammar. Anytime you want to have somethign selecting somethign based on expression structure, it is a grammar. Such metafonction systems ar eusualyl brittle or not extensible enough. ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] Defining the result domain of a proto operator
On 26/08/2011 16:45, Eric Niebler wrote: Before I answer, can you tell me why you've decided to put vector and matrix operations into separate domains? This seems like an artificial and unnecessary separation to me. Some operations are valid on vectors but not on matrices. Our grammar enforces that dimensions are consistent, and that requires us encoding the "meta" type of an expression into its domain. ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] Defining the result domain of a proto operator
On 8/26/2011 11:18 AM, Eric Niebler wrote: On 8/26/2011 10:56 AM, Joel Falcou wrote: On 26/08/2011 16:45, Eric Niebler wrote: Before I answer, can you tell me why you've decided to put vector and matrix operations into separate domains? This seems like an artificial and unnecessary separation to me. We have a system of specialisation where being able to make this distinction allowed us to replace sub proto tree by a pregenerated call to some BLAS functions or to apply some other Linear Algebra math based simplification. We also have a covector domain which allow us to know that : covector * vector is a dot product while vector * covector generate a matrix. In the same way, covector * matrix and matrix * vector can be recognized and handled in a proper way. Why can't you use a grammar to recognize patterns like these and take appropriate action? I solved this kind of problem by tagging the various types in traits structs and then embedding these traits in the transforms for the various operations. Here are examples of my expression, grammar, and binary function definitions: https://github.com/brandon-kohn/Geometrix/blob/master/geometrix/algebra/expression.hpp https://github.com/brandon-kohn/Geometrix/blob/master/geometrix/algebra/grammar.hpp https://github.com/brandon-kohn/Geometrix/blob/master/geometrix/algebra/binary_functions.hpp I'm not sure if this is the best way to do these, but it does work. Cheers, Brandon ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] Defining the result domain of a proto operator
On 26/08/2011 17:18, Eric Niebler wrote: Why can't you use a grammar to recognize patterns like these and take appropriate action? we do. Another point is that container based operation in our system need to know the number of dimension of the container. Domains carry this dimensions informations as we dont want to mix different sized container in a same expression. The containers we have are : table which can have 1 to MAX_DIM dimesnions matrix which behave as table<2> when mixed with table covector and vector that act as a matrix when mixed with matrix adn table<2> with table. The domain are then flagged with this dimension informations. ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] Defining the result domain of a proto operator
On 8/26/2011 10:56 AM, Joel Falcou wrote: > On 26/08/2011 16:45, Eric Niebler wrote: >> Before I answer, can you tell me why you've decided to put vector and >> matrix operations into separate domains? This seems like an artificial >> and unnecessary separation to me. > > We have a system of specialisation where being able to make this > distinction allowed us to replace sub proto tree by a pregenerated call > to some BLAS functions or to apply some other Linear Algebra math based > simplification. > > We also have a covector domain which allow us to know that : covector * > vector is a dot product while vector * covector generate a matrix. In > the same way, covector * matrix and matrix * vector can be recognized > and handled in a proper way. Why can't you use a grammar to recognize patterns like these and take appropriate action? -- Eric Niebler BoostPro Computing http://www.boostpro.com ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] Defining the result domain of a proto operator
On 26/08/2011 16:45, Eric Niebler wrote: Before I answer, can you tell me why you've decided to put vector and matrix operations into separate domains? This seems like an artificial and unnecessary separation to me. We have a system of specialisation where being able to make this distinction allowed us to replace sub proto tree by a pregenerated call to some BLAS functions or to apply some other Linear Algebra math based simplification. We also have a covector domain which allow us to know that : covector * vector is a dot product while vector * covector generate a matrix. In the same way, covector * matrix and matrix * vector can be recognized and handled in a proper way. ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] Defining the result domain of a proto operator
On 8/26/2011 10:25 AM, Mathias Gaunard wrote: > With the following Proto expression: > m * v; > > with m in the matrix_domain and v in the vector_domain. > vector_domain is a sub-domain of matrix_domain, so the common domain is > matrix_domain. > > We want the '*' operation to model the matrix multiplication. > matrix times vector yields a vector. > Therefore, the result of m * v should be in the vector_domain. > > If we define operator* ourselves, then we can easily put the domain we > want when calling proto::make_expr. > > However, using Proto-provided operator overloads, this doesn't appear to > be possible. > > Is there a mechanism in Proto to define how the domain of a node new > should be computed depending on the tag and the domains of the children? Before I answer, can you tell me why you've decided to put vector and matrix operations into separate domains? This seems like an artificial and unnecessary separation to me. -- Eric Niebler BoostPro Computing http://www.boostpro.com ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
[proto] Defining the result domain of a proto operator
With the following Proto expression: m * v; with m in the matrix_domain and v in the vector_domain. vector_domain is a sub-domain of matrix_domain, so the common domain is matrix_domain. We want the '*' operation to model the matrix multiplication. matrix times vector yields a vector. Therefore, the result of m * v should be in the vector_domain. If we define operator* ourselves, then we can easily put the domain we want when calling proto::make_expr. However, using Proto-provided operator overloads, this doesn't appear to be possible. Is there a mechanism in Proto to define how the domain of a node new should be computed depending on the tag and the domains of the children? ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
