Hey,
2014-06-10 22:23 GMT+02:00 Karl Rupp <r...@iue.tuwien.ac.at>:
> Hi,
>
> > A couple of months a go we already discussed the introduction of :
> > reduce_rows<op_add>(A) vs reduce<op_add>(row_wise(A))
> >
> > And concluded that the latter option would lead to higher compilation
> > times for not so much benefits.
> >
> > However, the more I think about it, the more I believe that reductions
> > should be just internal tools and that we should provide direct
> > shortcuts instead:
> >
> > sum(x), max(x), min(x), argmax(x), argmin(x)
> >
> > In this case, it would make much more sense to have
> >
> > sum(row_wise(A)), max(row_wise(A)), etc...
>
> I like this :-) Which operations do we want to support? I think we
> should cover the ones in MPI and OpenMP, i.e.
> min(), max(), sum(), and prod(),
> where the latter computes the product of all entries. For integers
> there's also (L/B)AND, (L/B)OR, (L/B)XOR, with L referring to 'logical'
> and 'B' to bitwise. OpenMP seems to allow a reduction with operator '-'
> as well, which is somewhat exotic. What about summing absolute values
> like in norm_1? What about summing squares as in norm_2()? It would be
> nice to have them covered so that we don't need separate implementations
> for the norms.
>
>
>
Yes, these seem fine. I've thought about argmax, argmin, but I think we
should wait until we have some vector indexing mechanism before providing
them. I've rarely seen argmax/argmin used on their own.
> rather than
> >
> > sum_rows, max_rows, etc...
> >
> > So I think that it could actually make sense to introduce
> > {row|col}_wise(). Any thought?
>
> How should row_wise(A) look implementation-wise? We can't make it a
> vector_base, because of the padding of A (there is no range-object which
> hides the zeros). This leaves us with matrix_expression, which is
> probably okay (yet not a beauty), as it allows for easier overloading of
> sum(), max(), etc.
>
Actually, everything that row_wise needs is to redirect to reduce_rows.
There is no row_wise in the scheduler. So, max(row_wise(A)) would just
redirect to reduce_rows<max>(A), which returns:
viennacl::vector_expression<const matrix_base<NumericT>, const
matrix_base<NumericT>, viennacl::op_reduce_rows<
viennacl::op_element_binary<op_max> > >(mat, mat);
However. I feel like this should be changed to
vector_expression<matrix_expression<..,..,op_element_unary<row_wise>,
matrix_expression<..,..,op_element_unary<row_wise>,
op_reduce<op_max> >(row_wise(A), row_wise(A))
But it's not a priority (requires careful changes in the generator, and I'm
really busy with other stuff now)
If that's ok, I'll probably add this interface while I'm done with merging
the generator. (Don't want to integrate any API change when it'll have to
be merged with master ;))
Philippe
Best regards,
> Karli
>
>
>
> ------------------------------------------------------------------------------
> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
> Find What Matters Most in Your Big Data with HPCC Systems
> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
> http://p.sf.net/sfu/hpccsystems
> _______________________________________________
> ViennaCL-devel mailing list
> ViennaCL-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/viennacl-devel
>
------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
_______________________________________________
ViennaCL-devel mailing list
ViennaCL-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/viennacl-devel
