Hi Toby,
2014-06-20 0:09 GMT+02:00 Toby St Clere Smithe <m...@tsmithe.net>:
> 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.
>
This is a bit strange because I remember that all the tests passed when I
merged the change! I'm not sure why up-casting (I guess you didn't mean
down-casting?) would be necessary, I have not understood your explanation.
I can't see the connection between up-casting and such recursive class
creation.
>
> 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<>.
>
The layout template parameter of matrix<SCALARTYPE, LAYOUT> is only there
to initialize the layout attribute matrix_base<SCALARTYPE>::row_major_;
Upcasting should still be legal and I don't understand why you would need a
reinterpret_cast<> when up-casting a pointer-to-derived to a
pointer-to-base. Keep in mind that such a cast is perfectly clean from a
C++ point of view. It just means "I want to use the instance of the base
class which exists inside the derived class".
static_cast<matrix_base<SCALARTYPE>* >(matrix<SCALARTYPE,
LAYOUT>*)->row_major() looks perfectly clean and legal to me. I don't know
if it helps though, since it seems like I haven't grasp the root of that
class proliferation thing :p
>
> 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?
>
If all of this comes from supporting slices of slices. I should point out
that this feature looks unnecessary to me :P
Indeed, a slice (a1, b1) of a slice (a2, b2) can just be replaced by a
single slice (a1*a2, b1*b2), so I can't think if any clear use case where
this type would be necessary.
Slices of ranges, though, should be supported. Does that problem forces you
to leave that unsupported as well?
Good night!
Philippe
> Best,
>
> Toby
>
>
>
> --
> Toby St Clere Smithe
> http://tsmithe.net
>
>
>
> ------------------------------------------------------------------------------
> 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
