Hey,

Yes, we could do that. The drawback is longer compilation when only vectors
are needed. For example, I can resolve my circular dependency problem by
adding #include "viennacl/matrix.hpp" above #include "viennacl/vector.hpp"
in "tests/vector_float_double.cpp" Including "matrix.hpp" in the generator
won't work, though. (I get missing definitions in the ocl namespace,
strangely...). Probably I could solve this problem by changing the order of
the includes in the generator, but still it would require to import
everything related to matrices even when you're gonna use vectors only.
This is why I haven't done it yet...

Philippe


2014-05-26 17:44 GMT+02:00 Karl Rupp <r...@iue.tuwien.ac.at>:

> Hey,
>
>
> > Yes, I feel like we would to do this whenever the vector and matrix
>
>> kernels are handled by the same backend ( generator, blas linker, or
>> whatever). Indeed, there are some operators in matrix_base so it will be
>> complicated to split things up. The core circular dependency seems to be
>> in the scheduler, which is required for the operators, but at the same
>> time requires the operator (through the use of traits on matrix_base<>*
>> objects). I'll see what I can do to decouple the operators from the
>> attributes. Nightmares in perspective. :D
>>
>
> well, on the other hand, considering that we need matrix.hpp in the
> scheduler anyway, what about a closer coupling of vector.hpp and matrix.hpp
> (plus sparse types)? Clearly, the scheduler can only work if it knows all
> the types, so it will have to pull in all the definitions. Is this an
> easier path?
>
> Best regards,
> Karli
>
------------------------------------------------------------------------------
The best possible search technologies are now affordable for all companies.
Download your FREE open source Enterprise Search Engine today!
Our experts will assist you in its installation for $59/mo, no commitment.
Test it for FREE on our Cloud platform anytime!
http://pubads.g.doubleclick.net/gampad/clk?id=145328191&iu=/4140/ostg.clktrk
_______________________________________________
ViennaCL-devel mailing list
ViennaCL-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/viennacl-devel

Reply via email to