Hey,

> Oh, this does look hackish indeed.
>
> ===============
> type : COMPOUND_OPERATION
> operator : OPERATION_BINARY_ADD_TYPE
> LHS : UNDEFINED
> RHS : UNDEFINED
> ===============
> Would probably be better. But how can this be represented by an
> expression template? Do we have any null type in ViennaCL?

Well, this doesn't make sense, since it has no data associated ;-)
We currently encode our operation as

     struct op_element
     {
       operation_node_type_family   type_family;
       operation_node_type          type;
     };

so we could encode it as

 > Node 1
 > ===============
 > operator family : OPERATION_UNARY_REDUCTION_TYPE_FAMILY
 > operator type : OPERATION_BINARY_ADD_TYPE
 > LHS : Node 2    <--- here is the data
 > RHS : UNDEFINED
 > ===============

Here, OPERATION_UNARY_REDUCTION_FAMILY is the 'type family', while 
OPERATION_BINARY_ADD_TYPE is the actual operation type. Note that
OPERATION_BINARY_ADD_TYPE is part of OPERATION_UNARY_REDUCTION_FAMILY as 
well as OPERATION_BINARY_TYPE_FAMILY, which may be undesired. On the 
other hand, I don't see a reason for introducing the constant
OPERATION_REDUCTION_ADD_TYPE,
since the pair {type_family,type} uniquely describes the operation.

Probably it's even worth to replace the current enum values
   OPERATION_UNARY_ABS_TYPE,
   OPERATION_UNARY_ACOS_TYPE,
   OPERATION_UNARY_ASIN_TYPE,
   ...
   OPERATION_BINARY_ACCESS_TYPE,
   OPERATION_BINARY_ASSIGN_TYPE,
   OPERATION_BINARY_INPLACE_ADD_TYPE,
   ...
with the more compact identifiers
   OPERATION_ABS_TYPE,
   OPERATION_ACOS_TYPE,
   OPERATION_ASIN_TYPE,
   ...
   OPERATION_ACCESS_TYPE,
   OPERATION_ASSIGN_TYPE,
   OPERATION_INPLACE_ADD_TYPE,
   ...



>     Expression templates are to some extent needed to efficiently build
>     up the expression tree. Even though I'd prefer to select the
>     operations at runtime, I can't think of a way to efficiently modify
>     the reduce<> interface for pure runtime arguments. Instead, we could use
>       viennacl::row_reduce<op>(A);
>       viennacl::column_reduce<op>(A)__;
>       viennacl::reduce<op>(x);
>     in order to avoid the introduction of viennacl::row_wise() and
>     viennacl::col_wise() without any useful semantics outside reduce().
>     What's your opinion about this?
>
>
> This is probably the best solution indeed.

Alright, then let's go with this. :-)

Best regards,
Karli


------------------------------------------------------------------------------
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
_______________________________________________
ViennaCL-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/viennacl-devel

Reply via email to