Sounds good.

On Aug 23, 2013, at 10:18 PM, Anoop Sam John <notifications@github.com>
wrote:

In
src/main/java/com/salesforce/phoenix/expression/aggregator/BaseDecimalStddevAggregator.java:

> +
> +    public BaseDecimalStddevAggregator(List<Expression> exps) {
> +        this.stdDevColExp = exps.get(0);
> +    }
> +
> +    @Override
> +    protected int getBufferLength() {
> +        return PDataType.DECIMAL.getByteSize();
> +    }
> +
> +    @Override
> +    public boolean evaluate(Tuple tuple, ImmutableBytesWritable ptr) {
> +        if (cachedResult == null) {
> +            BigDecimal ssd = sumSquaredDeviation();
> +            ssd = ssd.divide(new BigDecimal(getDataPointsCount()), MathContext.DECIMAL128);
> +            cachedResult = new BigDecimal(Math.sqrt(ssd.doubleValue()));

I think he concludes that it is coming not as precision exact as expected.
When the precision need is <= double precision, going with Math.sqrt(on
doubleValue) looks better and obviously faster also. What about doing this
way? Using the algorithm in the link given by
@tonyhuang<https://github.com/tonyhuang>, we will calculate the
precision for the stddev (based on the input
BigDecimals, using the OTHER algo part) and if it is less than or equal the
double precision we will go with the way in the current pull req code. If
more, we will go with the above algo. Ya still it wont be that accurate
precision but will be better than double value. I am trying to add these in
a BigDecimalUtil class which will have sqrt() method. That util will handle
all these work. Sounds reasonable?

—
Reply to this email directly or view it on
GitHub<https://github.com/forcedotcom/phoenix/pull/386/files#r5965214>
.