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