Hi Philippe, > I am done implementing : > x = viennacl::reduce<op>(viennacl::rows(A)); > x = viennacl::reduce<op>(viennacl::cols(A)); > s = viennacl::reduce<op>(x); > In the generator. For now, the op supported are : add, mult, max, min. I > can't support them all, because I need to provide their neutral element > for kernel generation (so that the shared memory can be initialized with > the neutral element)
Great, thanks! > I am now working on repmat. About this, I am not sure which should be > the return type of the API function. I am planning to go for some > > matrix_expression<matrix, viennacl::tuple<int,int>, op_repmat>(A, > make_tuple(repsize1,repsize2)) ? > > Where the tuple would get translated by the scheduler into a binary tree > with operator OP_TUPLE. Does this sound reasonable? Yes, sounds reasonable and integrates well into the current expression handling. What about using std::pair<> instead of viennacl::tuple? We only have vector_tuple<> in use so far, so I'd prefer to reuse std::pair rather than introducing a 'tuple' type in ViennaCL just for representing a pair. > @Toby : There might be some changes of this type in the way the > scheduler's expression tree is generated (for the need of the kernel > generator). I'll try to keep a list of the changes updated, so that the > python wrapper does not diverge too much from the core :) This is why we have discrete releases as well, not just the git repository :-) Best regards, Karli ------------------------------------------------------------------------------ Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk _______________________________________________ ViennaCL-devel mailing list ViennaCL-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/viennacl-devel
