Hey, > > If yes,I think that it should be changed > > because this easily violates the axioms of a norm : we can have > > norm(alpha*v) != alpha*norm(v) because of the rounding. > > This will usually be the case even if we change it. There are good > reasons why Clang emits warnings when using != or == for floating point > comparisons ;-) > > > I know that ;) But I'd say that the error we make for norm2 using float > is still stable. For integers, I doubt it is :p
What do you consider as 'stable' here? Even integer results can be stable in the sense that your error will be less than one in modulus ;-) > > I think that norm_*(vector<int>) should be changed to float > > norm_*(vector<int>). Any thoughts? > > There is no need to change it for anything for norm_1 and norm_inf. So, > the only relevant implementation case is norm_2, for which ublas uses > the same type convention we use now (at least that's what I found when I > looked it up). Although a floating point return type is probably more > often desired than an integer type, it would certainly complicate the > implementation. Moreover, it would introduce inconsistency, which I'm > not very fond of. The other thing, of course, is that it complicates the > implementation considerably (which floating point type to return? float > is not great in terms of precision, but double may not be available on > the GPU...). > > I'm open to using a different approach than what we have now, but I'd > like to hear solid arguments in favor of a change ;-) > > > Well, this implementation problem already exists! The sqrt() functions > only takes float/double as input (except std11's sqrt which casts to > double). As a result, norm_2() is actually disabled for integers (I had > not noticed it in my first e-mail) ;). This makes a lot of sense to > disable it, indeed. This leads to another question, though. Should we > add on the todo list some casting operators such as : > viennacl::norm_2(viennacl::cast<float>(v_int)). > For opencl, these can be easily handled by the generator. 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. In contrast, an explicit any-to-any conversion can be covered with 10x10=100 kernels, ultimately resulting in the same functionality for our users. I expect that the lower performance due to an explicit conversion/duplication is negligible in typical use cases. 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
