Hi Toby, I think you can conveniently resolve all these troubles by observing that matrix_slice<T> should be handled directly through its base type matrix_base<typename T::cpu_value_type> This way you can even nest multiple slices and ranges (all resulting in objects of type matrix_base<>) and don't need to worry about any explosion of template instantiations.
Best regards, Karli On 06/20/2014 12:09 AM, Toby St Clere Smithe wrote: > Hi all, > > In merging Philippe's changes to bring PyViennaCL up to date with > ViennaCL master, I've noticed that the removal of the layout parameter > from the matrix_base<> template (but not the matrix<> template) is > causing a bit of trouble. Previously I would down-cast (for example) > matrix_slice<matrix<> > to matrix_slice<matrix_base<> >, because > otherwise we would get a proliferation of classes that would each look > incompatible to Python, such as > > matrix_slice<matrix<> >, > matrix_slice<matrix_slice<matrix> > >, > matrix_slice<matrix_slice<matrix_slice<matrix> > > >, > > and so on. > > Now, since the layout parameter has gone, this down-casting has become > problematic, because it now loses some type information. One consequence > of this seems to be that some operations (in their current form) don't > work right. For instance, when adding a matrix_slice<matrix_base<> > to > a matrix<> of the same size, where the matrix_slice<matrix_base<> > has > been down-cast from matrix_slice<matrix_slice<matrix<> > >, all the > elements except those on the diagonal are incorrect. > > Of course, I can test the layout using matrix_base<>::row_major(), but > unless I do some hacky reinterpret_cast-ing, I don't see how I can use > this to stop the class proliferation above. And, naturally, the same > applies to matrix_range<>. > > I've got a couple of thoughts. Firstly, is the layout parameter also > going away for matrix<>, or are we keeping it for compatibility reasons? > Secondly, what is to be done? Ideally, from my perspective, the > down-casting would continue to work. I'm not sure what would need to be > changed in the core for this to be the case, and I can't prioritise > investigating it because I've still got to catch up my GSoC schedule! > (Exams only finished on the 11th.) > > Right now, I'll leave things as follows. I'll wrap > matrix_slice<matrix<>>, rather than matrix_slice<matrix_base<> >, and > leave taking slices of slices unsupported. I'm slightly uncomfortable > about this, not least because it leaves a regression in my test suite, > but it'll enable me to continue with the more urgent work. > > Any ideas? > > Best, > > Toby > > > ------------------------------------------------------------------------------ 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
