[ https://issues.apache.org/jira/browse/CASSANDRA-12417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15542002#comment-15542002 ]
Branimir Lambov commented on CASSANDRA-12417: --------------------------------------------- I wonder if the {{Int32Type}} etc. casts in the various {{compute}} methods are actually needed as the argument is already of the correct type and boxing is implied? Because of the "result must fit source type" logic, {{computeInternal()}} for both average implementations could return a long/double to avoid the box/unbox pair in the common non-overflow case. > Built-in AVG aggregate is much less useful than it should be > ------------------------------------------------------------ > > Key: CASSANDRA-12417 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12417 > Project: Cassandra > Issue Type: Bug > Components: CQL > Reporter: Branimir Lambov > Assignee: Alex Petrov > > For fixed-size integer types overflow is all but guaranteed to happen, > yielding incorrect result. While for sum it is somewhat acceptable as the > result cannot fit the type, this is not the case for average. > As the result of average is always within the scope of the source type, > failing to produce it only signifies a bad implementation. Yes, one can solve > this by type-casting, but do we really want to always have to be telling > people that the correct spelling of the average function is > {{cast(avg(cast(value as bigint))) as int)}}, especially if this is so > trivial to fix? > Additionally, the straightforward addition we use for floating point versions > is not a good choice numerically for larger numbers of values. We should > switch to a more stable version, e.g. iterative mean using {{avg = avg + > (value - avg) / count}}. -- This message was sent by Atlassian JIRA (v6.3.4#6332)