Hi, > This sounds reasonable indeed. I need casting operation_node_type for > the generator to control explicit casting within a generated kernel, but > it sounds very reasonable to only allow such constructors indeed.
The casting functionality can still be part of the generator, there's no reason why we should artifically cut down functionality. It's just that we can't provide a full-fledged user-API for it. > For > example, max(int, abs(int)) won't compile in OpenCL because abs returns > an unsigned int, therefore leading to an ambiguous call of max. Valid point. I remember that the behavior depends on the OpenCL SDK: Without additional care, a couple of the integer operations would fail with one SDK, but work well with another. > So, I > have to modify a bit the expression tree to invoke the generator for > with max(int, (int)abs(int)). > Now, adding an interface to allow: > x = viennacl::element_cast<float>(y) + z > for OpenCL only seems superfluous indeed. There are not enough use cases > to justify an interface divergence. > > However, having a very explicit constructor: > > viennacl::vector<float> x(viennacl::element_cast<float>(x_int)). > > may be better than > > viennacl::vector<float> x(x_int); > > Especially when a vector is constructed using operator=. That's a good point and brings us down to the question of how verbose we want the API to be. I'm leaning towards the shorter version without the element_cast because it is more intuitive, but we should go for the 'longer version' if there are two many pitfalls for the shorter version. Now, are there any such pitfalls? I can't think of any, actually: If a user creates a new vector, then the user is fine with creating a new object already. So, the only potential pitfall is that of accidentally losing precision. However, since we only support operations with the same scalar type, any loss of accuracy in one of the operands will result in a compilation error, so the user will receive a warning (btw: We should provide better diagnostics in such case, making/hacking the compiler message more explicit about what is the problem). > I can add this on the todo list for ViennaCL 1.6. It is a great feature > which could permit some great bandwidth savings as well as some > mixed-precision implementation. I just created an issue here: https://github.com/viennacl/viennacl-dev/issues/80 It's probably worth noting that we already have a mixed-precision conjugate gradient algorithm in ViennaCL, which is currently only supported for OpenCL. The only thing that is missing to make it backend agnostic are these conversion routines (not mixed precision operations...) Best regards, Karli ------------------------------------------------------------------------------ Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft _______________________________________________ ViennaCL-devel mailing list ViennaCL-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/viennacl-devel
