Hey
2014-06-24 12:29 GMT+02:00 Karl Rupp <r...@iue.tuwien.ac.at>:
> 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 ;-)
>
>
Let's not talk too much about this, we'll worry about machine epsilons
later :P
> > > 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.
>
>
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. 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. 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=.
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
Philippe
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
>
------------------------------------------------------------------------------
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
