impala-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Zach Amsden (Code Review)" <>
Subject [Impala-ASF-CR] IMPALA-4813: Round on divide and multiply
Date Fri, 24 Feb 2017 20:54:25 GMT
Zach Amsden has posted comments on this change.

Change subject: IMPALA-4813: Round on divide and multiply

Patch Set 2:


Thanks for the review!
Commit Message:

Line 44: | 46178777464.523809523847285 | 61076151920731.010714285714202    |
> why are these results not the same except for the least significant digit? 
This is the sum over many divisions, so you are seeing the compound error of truncation.
File be/src/exprs/

PS2, Line 682: ROUND
> I don't see why we need this. it happens that our Add() et al result types 
Multiply gets defined using this macro, and multiply needs round.  Otherwise, we don't need
an extra call to GetConstFnAttr to fetch an unused detail.
File be/src/runtime/decimal-value.h:

Line 124:       int result_scale, bool* overflow) const {
> where are these variants used?
Testing code, called from be/src/runtime/, which forges its own "column types"
without having any actual columns or FunctionContext from which to extract the scale and precision.

I'd be extremely happy to kill these and move them into the actual test instead of littering
all over this API, which because of the unused round parameter, already is getting a bit ugly
and overloaded.

PS2, Line 155: /* round */ true
> why?
So the decimal test always rounds :)  More precision as a result.

PS2, Line 169: /* round */ true
> same
Same reason.
File be/src/runtime/decimal-value.inline.h:

Line 153:   DCHECK_EQ(round, false);
> the DCHECK_EQ(result_scale, std::max(this_scale, other_scale)); means that 
I'm not opposed to removing these.  I inserted them mostly to make sure I got the proper overloads
for the test cases.

Line 176:   DCHECK_EQ(round, false);
> same

PS2, Line 200: shift_width
> ShiftWidth
This is now feeling very much like something that belongs in be/src/utils/somewhere

Line 294:       result = scaled_down;
> how about factoring this out into subroutine rather than duplicating?

PS2, Line 328: 127
> should this be 255? (or rather, shift_width()?)
No, r is defined to be int128_t.

However, the round can overflow - we need a bounds check here.

PS2, Line 340: 127
> shift_width()?
Will abstract this out to a rounding helper.  I wrote this before I needed the helper.

Line 353:   DCHECK_EQ(round, false);
> same

To view, visit
To unsubscribe, visit

Gerrit-MessageType: comment
Gerrit-Change-Id: Ie6bfcbe37555b74598d409c6f84f06b0ae5c4312
Gerrit-PatchSet: 2
Gerrit-Project: Impala-ASF
Gerrit-Branch: master
Gerrit-Owner: Zach Amsden <>
Gerrit-Reviewer: Dan Hecht <>
Gerrit-Reviewer: Michael Ho
Gerrit-Reviewer: Zach Amsden <>
Gerrit-HasComments: Yes

View raw message