Hi, Karl Rupp <r...@iue.tuwien.ac.at> writes: > Hmm, do we have enough use cases for this? I'd rather handle this > through an explicit conversion step, i.e. > viennacl::vector<float> v_float(v_int); > viennacl::norm_2(v_float); > instead of integrating more complexity into how we handle the various > operations. The explicit conversion can be provided in a controlled > manner (the number of any-to-any-conversions is still manageable), > whereas the introduction of casting would immediately blow up the > possible input combinations for *all* the operations. For example, the > operation > x = y + z > with the current requirement of the same scalar types for x, y, and z > results in ~10 different input combinations (four signed integer types, > four unsigned types, two floating point types). If we allow any > combinations through casting, this would make it 1000 combinations. > OpenCL would certainly help with jit-ting this, but compilation times > for CUDA and OpenMP would certainly explode if we want to provide these > operations through a shared library interface later.
Bear in mind also that PyViennaCL is such a shared library interface right now, and already has a fairly demanding compilation! One quick question: does the explicit conversion step allocate any new memory, or is it treated like a cast? Best, Toby ------------------------------------------------------------------------------ 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
