Hi,
2014-06-23 11:06 GMT+02:00 Karl Rupp <[email protected]>:
> Hi,
>
> > I've noticed in the source code that the result for norm_*(vector<int>)
> > was also an int. Am I correct?
>
> Yes, you are.
>
> > 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
> > 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.
Philippe
> Best regards,
> Karli
>
>
>
> ------------------------------------------------------------------------------
> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
> Find What Matters Most in Your Big Data with HPCC Systems
> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
> http://p.sf.net/sfu/hpccsystems
> _______________________________________________
> ViennaCL-devel mailing list
> [email protected]
> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/viennacl-devel
