2014-02-12 16:42 GMT+01:00 Karl Rupp <r...@iue.tuwien.ac.at>:
> Hey,
>
>
> > So, as of now, the generation of row-wise reduction can be triggered
>
>> through the interface:
>>
>> viennacl::reduce<op_add>(viennacl::row_wise(Mat))
>> viennacl::reduce<op_max>(viennacl::col_wise(Mat))
>> viennacl::reduce<op_min>(Vec)
>>
>> This plugs into a statement under the form:
>>
>> ----------------------------------
>> Node 1
>> ==============
>> type : COMPOUND_OPERATION
>> operator : OPERATION_UNARY_REDUCTION
>> lhs : Node 2
>> rhs : OPERATION_BINARY_ADD_TYPE
>>
>
> Are you sure about encoding OPERATION_BINARY_ADD_TYPE as RHS? This looks
> like a hack to me, not a clean solution.
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?
>
>
>
>> Node 2
>> ==============
>> type : COMPOUND_OPERATION
>> operator : OPERATION_UNARY_ROW_WISE_TYPE
>> lhs : MATRIX
>> rhs : UNDEFINED
>> ------------------------------------
>>
>
> Yep, I agree with this.
>
>
>
> I think that an operator is a symbolic entity, and that the difference
>> between an elementwise addition and a vector summation should not be
>> encoded at the level of the addition operation. This is why in both
>> cases the same OPERATION_BINARY_ADD_TYPE will be involved.
>>
>
> Agree.
>
>
>
> I think that the statement representation is nice enough, but the UI may
>> not be optimal from a compilation time perspective.
>>
>> On the other hand, calling
>>
>> viennacl::reduce(A, VIENNACL_ADD_ROW_WISE);
>>
>> seems not so great at all since this will involve a *lot* of duplication
>> in the scheduler and the generator. Yet, I don't see any way of having a
>> dynamic interface (no expression template) while preserving the
>> flexibility of the statement mentionned above. Any idea?
>>
>
> 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.
Best regards,
Philippe
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
ViennaCL-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/viennacl-devel
