Fix inconsistencies in aggregations and query library functions.

[chipkent]

Aggregation operations in query library functions and built-in query aggregations are inconsistent. This PR makes them consistent. Query library functions were changed.

• percentile now returns the primitive type.
• sum returns a widened type of double for floating point inputs or long for integer inputs.
• product returns a widened type of double for floating point inputs or long for integer inputs.
• cumsum returns a widened type of double[] for floating point inputs or long[] for integer inputs.
• cumprod returns a widened type of double[] for floating point inputs or long[] for integer inputs.
• wsum returns a widened type of long for all integer inputs and double for inputs containing floating points.

Note: Because the types have changed, the NULL return values have changed as well.

Resolves #4023

[rcaudy]

Should we handle infinities the way aggs do?

    private double currentValueWithSum(long totalNormalCount, long totalNanCount, long totalPositiveInfinityCount,
            long totalNegativeInfinityCount, double newSum) {
        if (totalNanCount > 0 || (totalPositiveInfinityCount > 0 && totalNegativeInfinityCount > 0)) {
            return Double.NaN;
        }
        if (totalNegativeInfinityCount > 0) {
            return Double.NEGATIVE_INFINITY;
        }
        if (totalPositiveInfinityCount > 0) {
            return Double.POSITIVE_INFINITY;
        }
        if (totalNormalCount == 0) {
            return QueryConstants.NULL_DOUBLE;
        }
        return (double) newSum;
    }

[chipkent]

They should give the same result, and the current impl has less branching. The current impl could be improved with a short circuit.

[chipkent]

With the new short circuit code, we have:

                if (isNaN(c) || isNaN(sum)) {
                    return Double.NaN;
                }

I think this is as good as we can do. We can only short circuit on NaN. The behavior should be the same as the aggs.

[chipkent]

Unit test added.

[rcaudy]

I think we're missing a hasInf case here. Presumably we need that to be Double.NaN or the correct sided-infinity, I'm honestly not sure which is the most consistent.

[chipkent]

Including the new short circuit logic, this is the code.

        try ( final ${pt.vectorIterator} vi = values.iterator() ) {
            while ( vi.hasNext() ) {
                final ${pt.primitive} c = vi.${pt.iteratorNext}();

                if (isNaN(c) || isNaN(prod)) {
                    return Double.NaN;
                } else if (Double.isInfinite(c)) {
                    if (hasZero) {
                        return Double.NaN;
                    }
                    hasInf = true;
                } else if (c == 0) {
                    if (hasInf) {
                        return Double.NaN;
                    }
                    hasZero = true;
                }

                if (!isNull(c)) {
                    count++;
                    prod *= c;
                }
            }
        }

        if (count == 0) {
            return NULL_DOUBLE;
        }

        return hasZero ? 0 : prod;

Infinite values behave as expected.

So the code here should be behaving properly.

[chipkent]

Unit test added.

[rcaudy]

We probably need the same kind of infinity handling as in sum.

[chipkent]

As in the other cases, the code should be handling infinity fine. Better short-circuiting was added.

[chipkent]

Unit test added.

[rcaudy]

Maybe missing infinity handling?

[chipkent]

Better short-circuiting was added. Infinity handling should be fine.

[chipkent]

Unit test added.

[rcaudy]

Do we need some infinity handling here?

[chipkent]

Better short-circuiting was added. Infinity handling should be fine.

[chipkent]

Unit test added.

[deephaven-internal]

Labels indicate documentation is required. Issues for documentation have been opened:

Community: deephaven/deephaven-docs-community#206