On 19 Feb, 2014, at 1:53 PM, slava77 <notifications@github.com> wrote:

> In RecoLocalTracker/SiStripClusterizer/src/ThreeThresholdAlgorithm.cc:
> 
> > @@ -80,19 +90,21 @@
> >  candidateAccepted() const {
> >    return ( !candidateLacksSeed &&
> >  	   noiseSquared * ClusterThresholdSquared
> > -	   <=  std::pow( std::accumulate(ADCs.begin(),ADCs.end(),float(0)), 2));
> > +	   <=  std::pow( float(std::accumulate(ADCs.begin(),ADCs.end(), int(0))), 2.f));
> 
> I can see logically that pow(x, int 2) can (and does in many cases) get optimized to x*x,
> but pow(x, 2.f) sounds pretty counter-intuitive that it should (except that it actually does, at least lately)
> http://bytes.com/topic/c/answers/806124-square-float-pow-f-f
> 
> Still, it sounds like it all depends on the weather conditions and performance can change by the year or an optimization option.
well this applies to almost any code. pow(x,2.f) is one of the safest I think.
> 
> I'd still really prefer x*x instead of all cases with pow(x, 2), whatever type the 2 has.
> I can imagine you wouldn't want to change it in this case, but I wouldn't take it as a guideline.
> 
CMSSW is plenty of pow(x,2). I changed many of its occurrencyes when the oppurtunity arose.
For sure I support ias a guideline not to abuse of pow(x,n)