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